Привет!
Я Дима Бардин, руководитель группы архитекторов Croc Code. Поговорим о ТЗ?
Все, кому приходилось участвовать в составлении технического задания для проекта, реагируют на буквы “ТЗ” в лучшем случае дергающимся глазом, в худшем — болью в районе ниже поясницы.
Недавно мы в Croc Code нащупали свой способ не требовать у наших клиентов функциональные/бизнес-требования или техническое задание, но оценить границы бюджета и потом, что важно, в него уложиться, разработать сервис, и получить довольного заказчика в лице страховой компании. Этим и хочу поделиться с Хабром.
Для страховых компаний и агентов в России страхование — это цифра в 1,5 млрд собранных премий и серьезный рынок, который несмотря на карантин вырос на 4% по итогу 2020 года.
Но пандемия все равно повлияла на сферу страхования. Из-за перехода на удаленную работу всем пришлось быстро придумывать и внедрять инструменты для этой самой удалёнки. И если у лидеров рынка, вроде АльфаСтрахования, Ингосстраха, Ренессанса, цифровизация шла давно и по плану, то средние и малые игроки на рынке долго тянули с переходом на цифру. Пользовались старым добрым принципом: работает — не трогай. А в случае разработки не всегда понятно, сколько денег нужно, чтобы это самое «потрогать».
Что именно «потрогать» в страховом деле — найдется. Тут тебе и расчет стоимости полиса, и документооборот, и выплата комиссионных вознаграждений посредникам, которые могут быть как физлицами, так и ИП или даже компаниями, и общение с клиентами, и миллион других внутренних процессов.
По итогу многие компании стали внедрять свои цифровые решения, чтобы эффективнее конкурировать за клиента с другими игроками на рынке.
Для этого у них есть ряд ключевых инструментов:
В конце 2020 года к нам обратилась страховая компания АСКО. Эта челябинская компания входит в 10-ку компаний по ОСАГО. Крепкий региональный страховщик, работает в Челябинске, Самаре, Екатеринбурге, Новосибирске.
Компания в домашних регионах вынуждена конкурировать с филиалами крупнейших страховых компаний, вроде Ингосстрах, Росгосстрах.
АСКО конкурирует не только за прямого потребителя, но и за агентов, т.к. страховки они продают в основном через агентов. Агенты приносят 80-90% продаж компании. Именно на них компания решила сделать ставку.
Два года назад АСКО приняли решение делать новый личный кабинет агента. У них есть старый, они им пользуются 10 лет. Он на устаревший архитектуре, с кодом, под который много раз приходилось подставлять костыли.
Понятно, что грохнуть это сложно, компания 10 лет развивала приложение, кастомные доработки делала. С другой стороны, новый функционал туда не привяжешь, т.к. если тронуть, начинает все рушиться.
Есть страховой агент. Агент приходит в офис, подписывает акт на эти бланки, чтобы в офисе знали, что именно он именно эти бланки взял. Дальше агент уходит продавать.
Агент находит покупателя, продает ему страховку. Заполняет бланки, одну копию клиенту, одну копию себе. Собирает эту стопку бумаг, приходит раз в месяц с ней и с деньгами в офис, сдает.
Эта стопка бумаг уезжает, к примеру, в Челябинск. Там все проверяют, если есть ошибки, присылают на исправление. Потом еще пару месяцев агент ждет свое вознаграждение.
Короче, много телодвижений, много людей задействовано, большой простор для ошибок и временной лаг будь здоров.
Новый процесс страхования:
Агент открывает личный кабинет, логин-пароль, данные клиента ввел, автоматически все посчиталось, отправляет клиенту ссылку на оплату. Клиенту приходит смс со ссылкой. Клиент оплачивает с карты. Деньги тут же списываются, привязываются. Полис оформлен, все довольны.
К примеру, АльфаСтрахование выдает полисы КАСКО именно так.
Многие процессы упростились, не надо никуда ходить. Плюс можно простой электронной подписью подписать документы в личном кабинете агента.
Поскольку ТЗ не было, мы решили для начала опросить страховых агентов: узнать их боли, составить карты эмпатии. На основе этого уже формировать MVP.
Чтобы избежать сжигания бюджета, мы решили в конце рабочей группы составлять заявку, в которой перечисляли:
Мы проводили рабочие группы с представителями бизнеса заказчика: директор по развитию, финансовый директор, зам ген директора, агенты, кураторы этих агентов, люди, отвечающие за взаиморасчеты. Со стороны Croc Code присутствовали дизайнер, менеджер и аналитик.
На встречах не присутствовали разработчики, ни с нашей стороны, ни со стороны заказчика.
Во время онлайн-встреч, рабочая группа обсуждала функционал, дизайнер параллельно накидывал прототип, правил его в реальном времени. Потом день дизайнер дорабатывал, и мы снова собирались, корректировали, правили, добавляли бизнес-процессы, собирали все дополнения по прототипу от стейкхолдеров. От заказчика были нужны минимальные усилия, они только смотрели и комментировали.
Во время рабочей группы мы вместе поняли, что нужно разрабатывать.
Решили сделать отдельный личный кабинет с новым функционалом для агентов, но при этом интегрировать в этот новый личный кабинет старую систему расчета оформления полисов на уровне виджетов. Плюс запланировали сделать сквозную интеграцию с точки зрения аутентификации.
К концу второй недели мы уже провели аналитику интеграции с системой заказчика: какие методы надо разработать, как данные ездят и прочее.
В конце спринта разработки есть итоговые часы, они или бьются, или не бьются, и мы готовим закрывающие документы. После оплаты формируем новую заявку.
Так заказчик точно знает, чем мы занимаемся ближайшие две недели, а мы идем маленькими шажками, с инкрементальным приращением результата.
Есть пролонгация, а есть очередной платеж, когда оплата за полис разбита на части, и платежи поступают в течение года. Об этом тоже агенты напоминают своим клиентам, и это теперь агент тоже может узнать через сервис.
Сейчас мы занимаемся взаиморасчетами, чтобы агент, заходя в приложение, сразу понимал, он должен компании денег за полисы или компания должна ему начислить комиссию. Агент должен — красненькая цифра, ему должны — зелененькая.
Очень простыми инструментами можно облегчить людям жизнь. Так мы добавили в личный кабинет интеллектуальный поиск, прикрутили электронную цифровую подпись. А еще теперь агенты могут отправить ссылку на оплату клиенту сразу в WhatsApp.
Среди преимуществ нашего краткосрочного планирования — реализация важных функций, о которых мы изначально не договаривались.
Мы сделали админку, в которой видно, какие агенты заходят и какой функциональностью пользуются. На основании этого создаем дашборды для нашего основного стейкхолдера — зам ген директора. Так он видит, какое количество полисов оформляется через эту систему и какое количество денег через нее проходит.
С помощью этого можно понять, какие бенефиты от приложения получает компания, и насколько это выгодное вложение. Система нужна не ради системы.
А еще мы сделали мобильную версию.
В тестировании вовлечены агенты из разных подразделений и разных регионов. Это помогает нам сориентироваться в бизнес-процессах, т.к. у заказчика они в регионах отличаются.
Первый раз мы привлекли 3 агентов, послушали, что они сказали, поправили некоторые штуки. После этого уже 6 агентов тестировали новый сервис. Потом уже 30 агентов подключились к тестированию.
Мотивация первых пользователей сервиса — банальное удобство. Это стало ясно, когда после выхода на 30 тестовых пользователей, количество пользователей без активных действий с нашей стороны увеличилось до 700. А это половина плановой аудитории — всего сервисом будут пользоваться около 1500 агентов.
Благодаря этому росту пользователей, у нас появилось понимание, какая нужна будет поддержка сервису, и сколько мы на это времени потратим.
Был случай, когда агенты даже уронили поддержку.
Раньше, когда агент авторизовался в сервисе, ему нужно было вводить логин лишь один раз. А в нашу систему нужно вводить логин каждый раз и с доменом. Люди не обращали внимание на это и не могли войти. Само собой, посыпались жалобы в поддержку, что сервис не работает. Мы экстренно сделали при входе напоминание, в каком формате вводить логин, - помогло.
Кстати, заранее такое предугадать сложно, а по дороге понять, что это нужно и полезно — легко. А раз нет ТЗ и о функционале мы договариваем тоже по дороге, то это не вызывает ни у кого вопросов.
Технические проблемы тоже иногда возникают, но чаще на стороне IT-инфраструктуры заказчика. Само собой, мы каждый раз разбираем проблему, а потом ставим эту задачу штатным разработчикам заказчика. Наши айтишники напрямую общаются с ними.
Сложности проекта
Во-первых, цена
Этот проект казался слишком маленьким по меркам Croc Code. На маленьких проектах нам трудно зарабатывать, у нас большие косты, и именно новый подход к проекту позволил его вывести на интересные цифры.
Небольших заказчиков пугают большие цифры в смете. Особенно если они не уверены в результате и не знают, сколько денег им принесет проект.
Благодаря постепенному планированию задач и ожидаемому результату на каждом этапе, заказчику проще. Он быстро видит свои выгоды от проекта. А когда он еще на стадии разработки становится выгодным, есть смысл развивать это направлению.
Во-вторых, специфика разработки
Фронтенд разработка - не целевой сегмент для нас. Croc Code разрабатывает фронт скорее как маленький кусочек в контексте огромного проекта. Мы впервые сделали акцент на фронтенд разработку. И даже попали в рынок по цене — предложили среднюю ставку по рынку.
В-третьих, гибкие методологии
Только в прошлом году в нашей компании появились специально обученные люди, которые стали переводить крупные проекты на гибкие модели управления. Но у средних и маленьких проектов таких специалистов нет. Так что выкручивались, как умеем.
Наконец, внутренний отдел разработки
Страховые компании часто пытаются нарезать ИТ-проекты на мелкие куски и реализовывать на своей стороне. В какой-то степени мы конкурируем с внутренней разработкой. Были ситуации, когда наши разработчики выполняли свою часть, а разработчики со стороны заказчика не успевали выполнить свою. Возникали небольшие простои.
Из особенностей работы — заказчик в Челябинске, +2 часа. Но это даже трудностью назвать нельзя, мы легко подстроились.
Поначалу нужно было преодолеть некоторый скепсис, но мы смогли это сделать, во многом благодаря нашей экспертности в отрасли и общению непосредственно с конечным пользователем.
Почему проект сработал “как надо”
В завершении хочу привести пару-тройку примеров, когда отсутствие ТЗ играло нам на руку и упрощало процесс работы. Была ситуация, когда заказчик в процессе решил сменить бизнес-процесс, рассказал об этом на рабочей группе и мы включили эти исправления в ближайший спринт разработки. Минусы ТЗ в том, что если мы не учли какой-то бизнес-процесс, то придется что-то менять, а с готовым ТЗ это проблематично. Плюс непредвиденные ситуации проще решать.
Еще была ситуация, когда мы договора перегружали, и нечаянно спарсили ошибку, которая была в базе данных заказчика. Ее только руками можно почистить, а для этого гору документов перебрать придется. Косяк есть, а кто в нем виноват - непонятно. Было бы ТЗ - скорее всего, начались бы трения. А так мы по дороге подобные косяки спокойно решали.
По итогу у нас сложились чуть ли не семейные отношения с заказчиком, настолько все без формализмов и легко пошло. И самое приятное в этом проекте, что от заказчика вообще нет негатива. Все, что мы делаем, мы с ним согласовываем, само собой привносим и технологическую и отраслевую экспертизу, но промахи все равно случаются. Но когда все обсуждение и планирование идет на небольшом промежутке времени, заказчик понимает и помнит, что мы с ним решение какой-то всплывшей проблемы не обсуждали, и с пониманием относится к тому, что надо что-то доработать.
Когда мы предлагаем теперь другим заказчикам что-то делать без ТЗ, то слышим восторг. Многим тяжело вести проекты “по классике”. Сначала заказчик год пишет ТЗ, пока он его пишет, оно устаревает. Формат такой работы оказался очень востребованным на рынке. Мобильность явно всех радует.
habr.com
Я Дима Бардин, руководитель группы архитекторов Croc Code. Поговорим о ТЗ?
Все, кому приходилось участвовать в составлении технического задания для проекта, реагируют на буквы “ТЗ” в лучшем случае дергающимся глазом, в худшем — болью в районе ниже поясницы.
Недавно мы в Croc Code нащупали свой способ не требовать у наших клиентов функциональные/бизнес-требования или техническое задание, но оценить границы бюджета и потом, что важно, в него уложиться, разработать сервис, и получить довольного заказчика в лице страховой компании. Этим и хочу поделиться с Хабром.
Что такое страхование
Для большинства людей страхование — это ОСАГО или Каско для автомобиля, страховка для путешествия, которая нужна для получения визы, а также “финансовая защита”, которая позволяет получить супер-низкую ставку, когда берешь кредит в банке. Иногда еще в поле зрения попадают забавные случаи «звездных» страховок, вроде ягодиц Дженифер Лопес по $300 млн. В последнее время еще стала популярной страховка от COVID-19.Для страховых компаний и агентов в России страхование — это цифра в 1,5 млрд собранных премий и серьезный рынок, который несмотря на карантин вырос на 4% по итогу 2020 года.
Но пандемия все равно повлияла на сферу страхования. Из-за перехода на удаленную работу всем пришлось быстро придумывать и внедрять инструменты для этой самой удалёнки. И если у лидеров рынка, вроде АльфаСтрахования, Ингосстраха, Ренессанса, цифровизация шла давно и по плану, то средние и малые игроки на рынке долго тянули с переходом на цифру. Пользовались старым добрым принципом: работает — не трогай. А в случае разработки не всегда понятно, сколько денег нужно, чтобы это самое «потрогать».
Что именно «потрогать» в страховом деле — найдется. Тут тебе и расчет стоимости полиса, и документооборот, и выплата комиссионных вознаграждений посредникам, которые могут быть как физлицами, так и ИП или даже компаниями, и общение с клиентами, и миллион других внутренних процессов.
По итогу многие компании стали внедрять свои цифровые решения, чтобы эффективнее конкурировать за клиента с другими игроками на рынке.
Конкуренция на страховом рынке
Если посмотреть со стороны страховой компании, то продажи в значительной степени осуществляются посредниками: агентами, банками, автодилерами, розничными сетями, а теперь еще и крупными экосистемами (как Яндекс), которые организуют продажи страховых продуктов уже непосредственно своим клиентам — в рамках так называемых В2В и В2В2С-моделей. Доля прямых продаж у страховых компаний невелика. Поэтому они конкурируют друг с другом за посредников.Для этого у них есть ряд ключевых инструментов:
- Классные страховки. Это продуктовые предложения, состоящие из страхового покрытия, которые закрывают нужные людям риски, а также процесса к организации страховых выплат: насколько он прост, быстр и удобен. Для партнеров важна “заточка” страховок под его бизнес и тематику работы, чтобы было легко продавать их вместе со своим продуктом (страховка на технику при продаже электроники в магазине и т.д.). В идеале это должны быть страховки, которые понятно и реально работают: по ним лечат, чинят авто, выплачивают деньги (причем важно, чтобы это происходило без дополнительного головняка, легко и просто).
- Уровень комиссионного вознаграждения посредника. Чем больше комиссия, тем партнерам интереснее и приятнее продавать такую страховку. В каждой ситуации это поиск баланса итоговой стоимости цены для клиента и наполнения продукта с конкуренцией за место в голове продавца или на полке.
- Современные технологии и бизнес-процессы.
В конце 2020 года к нам обратилась страховая компания АСКО. Эта челябинская компания входит в 10-ку компаний по ОСАГО. Крепкий региональный страховщик, работает в Челябинске, Самаре, Екатеринбурге, Новосибирске.
Компания в домашних регионах вынуждена конкурировать с филиалами крупнейших страховых компаний, вроде Ингосстрах, Росгосстрах.
АСКО конкурирует не только за прямого потребителя, но и за агентов, т.к. страховки они продают в основном через агентов. Агенты приносят 80-90% продаж компании. Именно на них компания решила сделать ставку.
Подготовка к проекту «ЛК Страхового агента»
Наш проект, с одной стороны, вписан в логику общей цифровизации, но в первую очередь, для заказчика — это техническое средство конкуренции с топовыми компаниями.Два года назад АСКО приняли решение делать новый личный кабинет агента. У них есть старый, они им пользуются 10 лет. Он на устаревший архитектуре, с кодом, под который много раз приходилось подставлять костыли.
Понятно, что грохнуть это сложно, компания 10 лет развивала приложение, кастомные доработки делала. С другой стороны, новый функционал туда не привяжешь, т.к. если тронуть, начинает все рушиться.
Входные данные
Этот проект для нас необычен. После общения с заказчиком мы выяснили, что:- Заказчики хотели сделать для агентов что-то офигительное, но что именно делать, решить не могли.
- Еще у них не было ТЗ.
- Писать они его не собирались.
- Заказчик хотел работать по гибким методологиям.
- Вишенка на торте — этот проект был в десятки раз скромнее по бюджету, чем те, над которыми обычно работает наша компания.
Бизнес-процессы в страховании
В простом приближении старый процесс страхования выглядел так:Есть страховой агент. Агент приходит в офис, подписывает акт на эти бланки, чтобы в офисе знали, что именно он именно эти бланки взял. Дальше агент уходит продавать.
Агент находит покупателя, продает ему страховку. Заполняет бланки, одну копию клиенту, одну копию себе. Собирает эту стопку бумаг, приходит раз в месяц с ней и с деньгами в офис, сдает.
Эта стопка бумаг уезжает, к примеру, в Челябинск. Там все проверяют, если есть ошибки, присылают на исправление. Потом еще пару месяцев агент ждет свое вознаграждение.
Короче, много телодвижений, много людей задействовано, большой простор для ошибок и временной лаг будь здоров.
Новый процесс страхования:
Агент открывает личный кабинет, логин-пароль, данные клиента ввел, автоматически все посчиталось, отправляет клиенту ссылку на оплату. Клиенту приходит смс со ссылкой. Клиент оплачивает с карты. Деньги тут же списываются, привязываются. Полис оформлен, все довольны.
К примеру, АльфаСтрахование выдает полисы КАСКО именно так.
Многие процессы упростились, не надо никуда ходить. Плюс можно простой электронной подписью подписать документы в личном кабинете агента.
Внедрение гибкого подхода
Само собой, перед тем, как браться за проект, мы сделали общий срез, посмотрели какой функционал есть в других страховых компаниях, как это выглядит.
Поскольку ТЗ не было, мы решили для начала опросить страховых агентов: узнать их боли, составить карты эмпатии. На основе этого уже формировать MVP.
Рабочий процесс
Если коротко, то наш рабочий процесс выглядел так:- 2 недели идет первая “рабочая группа”
- рабочая группа формирует заявку и передает задачи разработчикам
- 2 недели идет первый спринт разработки
- параллельно со спринтом разработки идет вторая рабочая группа
- рабочая группа формирует новую заявку и передает новые задачи разработчикам
Гибридный T&M
Time and materials — частая практика в кругах разработчиков. Только вот заказчики иногда нервничают. Неизвестно, сколько натикает этого «time» и какие на проект буду нужны «materials».Чтобы избежать сжигания бюджета, мы решили в конце рабочей группы составлять заявку, в которой перечисляли:
- какие работы выполним,
- каких специалистов задействуем,
- какой результат покажем,
- какой формат приемки устроит заказчика,
- какие плановые часы мы обещаем.
Рабочая группа
Так мы в проекте назвали встречи по планированию спринта. Встречи эти проходили трижды в неделю в течение 2-х недель.Мы проводили рабочие группы с представителями бизнеса заказчика: директор по развитию, финансовый директор, зам ген директора, агенты, кураторы этих агентов, люди, отвечающие за взаиморасчеты. Со стороны Croc Code присутствовали дизайнер, менеджер и аналитик.
На встречах не присутствовали разработчики, ни с нашей стороны, ни со стороны заказчика.
Во время онлайн-встреч, рабочая группа обсуждала функционал, дизайнер параллельно накидывал прототип, правил его в реальном времени. Потом день дизайнер дорабатывал, и мы снова собирались, корректировали, правили, добавляли бизнес-процессы, собирали все дополнения по прототипу от стейкхолдеров. От заказчика были нужны минимальные усилия, они только смотрели и комментировали.
Во время рабочей группы мы вместе поняли, что нужно разрабатывать.
Решили сделать отдельный личный кабинет с новым функционалом для агентов, но при этом интегрировать в этот новый личный кабинет старую систему расчета оформления полисов на уровне виджетов. Плюс запланировали сделать сквозную интеграцию с точки зрения аутентификации.
К концу второй недели мы уже провели аналитику интеграции с системой заказчика: какие методы надо разработать, как данные ездят и прочее.
Формальный процесс
Менеджер формирует заявку на спринт разработки. Отраслевой эксперт утверждает. Менеджер передает список фичей на оценку по времени разработчикам. Потом умножает часы на согласованную с заказчиком ставку, отсюда мы получаем целевую стоимость. После заявку отправляем заказчику, если нужно что-то правим, и после утверждаем с заказчиком.В конце спринта разработки есть итоговые часы, они или бьются, или не бьются, и мы готовим закрывающие документы. После оплаты формируем новую заявку.
Так заказчик точно знает, чем мы занимаемся ближайшие две недели, а мы идем маленькими шажками, с инкрементальным приращением результата.
Функционал
Сначала мы сделали пролонгацию ОСАГО. Реализовали функционал, который в системе подтягивает клиентов, у кого приближается дата пролонгации полиса. Когда у клиента полис через месяц заканчивается, агент это в личном кабинете видит.Есть пролонгация, а есть очередной платеж, когда оплата за полис разбита на части, и платежи поступают в течение года. Об этом тоже агенты напоминают своим клиентам, и это теперь агент тоже может узнать через сервис.
Сейчас мы занимаемся взаиморасчетами, чтобы агент, заходя в приложение, сразу понимал, он должен компании денег за полисы или компания должна ему начислить комиссию. Агент должен — красненькая цифра, ему должны — зелененькая.
Очень простыми инструментами можно облегчить людям жизнь. Так мы добавили в личный кабинет интеллектуальный поиск, прикрутили электронную цифровую подпись. А еще теперь агенты могут отправить ссылку на оплату клиенту сразу в WhatsApp.
Среди преимуществ нашего краткосрочного планирования — реализация важных функций, о которых мы изначально не договаривались.
Мы сделали админку, в которой видно, какие агенты заходят и какой функциональностью пользуются. На основании этого создаем дашборды для нашего основного стейкхолдера — зам ген директора. Так он видит, какое количество полисов оформляется через эту систему и какое количество денег через нее проходит.
С помощью этого можно понять, какие бенефиты от приложения получает компания, и насколько это выгодное вложение. Система нужна не ради системы.
А еще мы сделали мобильную версию.
Тестирование и поддержка
Все что мы разработали, мы конечно же тестируем.В тестировании вовлечены агенты из разных подразделений и разных регионов. Это помогает нам сориентироваться в бизнес-процессах, т.к. у заказчика они в регионах отличаются.
Первый раз мы привлекли 3 агентов, послушали, что они сказали, поправили некоторые штуки. После этого уже 6 агентов тестировали новый сервис. Потом уже 30 агентов подключились к тестированию.
Мотивация первых пользователей сервиса — банальное удобство. Это стало ясно, когда после выхода на 30 тестовых пользователей, количество пользователей без активных действий с нашей стороны увеличилось до 700. А это половина плановой аудитории — всего сервисом будут пользоваться около 1500 агентов.
Благодаря этому росту пользователей, у нас появилось понимание, какая нужна будет поддержка сервису, и сколько мы на это времени потратим.
Был случай, когда агенты даже уронили поддержку.
Раньше, когда агент авторизовался в сервисе, ему нужно было вводить логин лишь один раз. А в нашу систему нужно вводить логин каждый раз и с доменом. Люди не обращали внимание на это и не могли войти. Само собой, посыпались жалобы в поддержку, что сервис не работает. Мы экстренно сделали при входе напоминание, в каком формате вводить логин, - помогло.
Кстати, заранее такое предугадать сложно, а по дороге понять, что это нужно и полезно — легко. А раз нет ТЗ и о функционале мы договариваем тоже по дороге, то это не вызывает ни у кого вопросов.
Технические проблемы тоже иногда возникают, но чаще на стороне IT-инфраструктуры заказчика. Само собой, мы каждый раз разбираем проблему, а потом ставим эту задачу штатным разработчикам заказчика. Наши айтишники напрямую общаются с ними.
Сложности проекта
Во-первых, цена
Этот проект казался слишком маленьким по меркам Croc Code. На маленьких проектах нам трудно зарабатывать, у нас большие косты, и именно новый подход к проекту позволил его вывести на интересные цифры.
Небольших заказчиков пугают большие цифры в смете. Особенно если они не уверены в результате и не знают, сколько денег им принесет проект.
Благодаря постепенному планированию задач и ожидаемому результату на каждом этапе, заказчику проще. Он быстро видит свои выгоды от проекта. А когда он еще на стадии разработки становится выгодным, есть смысл развивать это направлению.
Во-вторых, специфика разработки
Фронтенд разработка - не целевой сегмент для нас. Croc Code разрабатывает фронт скорее как маленький кусочек в контексте огромного проекта. Мы впервые сделали акцент на фронтенд разработку. И даже попали в рынок по цене — предложили среднюю ставку по рынку.
В-третьих, гибкие методологии
Только в прошлом году в нашей компании появились специально обученные люди, которые стали переводить крупные проекты на гибкие модели управления. Но у средних и маленьких проектов таких специалистов нет. Так что выкручивались, как умеем.
Наконец, внутренний отдел разработки
Страховые компании часто пытаются нарезать ИТ-проекты на мелкие куски и реализовывать на своей стороне. В какой-то степени мы конкурируем с внутренней разработкой. Были ситуации, когда наши разработчики выполняли свою часть, а разработчики со стороны заказчика не успевали выполнить свою. Возникали небольшие простои.
Из особенностей работы — заказчик в Челябинске, +2 часа. Но это даже трудностью назвать нельзя, мы легко подстроились.
Поначалу нужно было преодолеть некоторый скепсис, но мы смогли это сделать, во многом благодаря нашей экспертности в отрасли и общению непосредственно с конечным пользователем.
Почему проект сработал “как надо”
- Экспертность со стороны Croc Code, а именно - наличие отраслевой экспертизы, и оттого - понимание внутренней «кухни» заказчика.
- У заказчика нет опыта организации такого процесса, нет методологии.
- Заказчики - люди занятые. Да, они вынуждены присутствовать на собраниях, но там они только говорят, а мы делаем. Им не надо тратить время на подготовку документов, где описано, что нам надо делать.
- У заказчика нет такого технологического ресурса. Причем выгодного - мы в рынке, наш ставки оказались даже ниже, чем заказчик рассчитывал.
В завершении хочу привести пару-тройку примеров, когда отсутствие ТЗ играло нам на руку и упрощало процесс работы. Была ситуация, когда заказчик в процессе решил сменить бизнес-процесс, рассказал об этом на рабочей группе и мы включили эти исправления в ближайший спринт разработки. Минусы ТЗ в том, что если мы не учли какой-то бизнес-процесс, то придется что-то менять, а с готовым ТЗ это проблематично. Плюс непредвиденные ситуации проще решать.
Еще была ситуация, когда мы договора перегружали, и нечаянно спарсили ошибку, которая была в базе данных заказчика. Ее только руками можно почистить, а для этого гору документов перебрать придется. Косяк есть, а кто в нем виноват - непонятно. Было бы ТЗ - скорее всего, начались бы трения. А так мы по дороге подобные косяки спокойно решали.
По итогу у нас сложились чуть ли не семейные отношения с заказчиком, настолько все без формализмов и легко пошло. И самое приятное в этом проекте, что от заказчика вообще нет негатива. Все, что мы делаем, мы с ним согласовываем, само собой привносим и технологическую и отраслевую экспертизу, но промахи все равно случаются. Но когда все обсуждение и планирование идет на небольшом промежутке времени, заказчик понимает и помнит, что мы с ним решение какой-то всплывшей проблемы не обсуждали, и с пониманием относится к тому, что надо что-то доработать.
Когда мы предлагаем теперь другим заказчикам что-то делать без ТЗ, то слышим восторг. Многим тяжело вести проекты “по классике”. Сначала заказчик год пишет ТЗ, пока он его пишет, оно устаревает. Формат такой работы оказался очень востребованным на рынке. Мобильность явно всех радует.
Как разработать без ТЗ так, чтобы результат был не ХЗ
Привет, Хабр! Я Дима Бардин, руководитель группы архитекторов Croc Code. Поговорим о ТЗ?Все, кому приходилось участвовать в составлении технического задания для проекта, реагируют на буквы “ТЗ” в...
habr.com