Полученные от клиента деньги: ~ 1 200 000 рублей
Потраченные на внешних разработчиков, лицензии: ~ 400 000 рублей
Срок проекта — 12 месяцев.
Время реальных работ с нашей стороны — 4 месяца
Отставание по срокам:
- фактическое — 1 месяц
- юридическое — отсутствует
Причины факапов
1) Все стремятся сделать задачу ко времени дедлайна, а не тогда, когда могут.
На проекте изначально была существенная проблема с тем, что все задачи имели конечные сроки, но выполнялись они именно ко сроку. В итоге было потеряно очень много времени.
Большой проблемой является то, что все ориентируются именно на дедлайн — то есть на точку времени к которой нужно сделать работу. Но на самом деле, к дедлайну нужно относиться как к точке, в которой эта работа уже должна быть выполнена.
Смотрите, во все временные расчеты мы закладываем запас — на проверки, на исправления и т. д. Что происходит, если задачи выполняются именно к дедлайну — в лучшем случае, мы просто бесполезно теряем все дополнительное время, которое было заложено. В худшем случае мы теряем и его и тратим как минимум столько же дополнительного времени.
Также, как мне кажется, временных планов должно быть 2: один публичный план — для заказчика, а второй план — для команды.
В план для заказчика можно закладывать страховочное время, а в плане для разработчиков стоит его сокращать.
Для повышения эффективности лучше назначать один дедлайн (без запасов) и несколько промежуточных точек, к которым должны быть достигнуты определенные результаты. Если «промежуточный дедлайн» был сорван — не стоит скрывать этот факт от заинтересованных сторон, и тем более надеяться все наверстать к следующей контрольной точке. Оцените последствия и влияние их на стратегические сроки, продумайте решение (а лучше несколько), затем придите к начальнику (или заказчику) и обсудите с ним возникшую ситуацию и возможные варианты решения.
Такой подход может хорошо работать при условии, что весь проект разбит на четкие и понятные этапы разработки + есть интерактивный ГАНТ, который будет учитывать положительные и отрицательные смещения сроков.
Я очень рекомендую прочитать книжку “Радикальная прямота” Ким Скотт.
2) Недооценка рисков и времени на задачи по:
- верстке
- программированию
- обратной интеграции OpenCart -> 1C
- интеграции с 1С
Отчасти, была проблема с изначальной оценкой по срокам - мы отошли от нашей типовой сметной оценки и полностью доверились оценке стороннего исполнителя, который не учел нюансов и затянул сроки.
Этого можно было избежать при:
-
Корректной и привычной нам оценке, базирующейся на декомпозиции по скринам до состояния “фич”. Бюджет проекта был посчитан по этой схеме, но оценку по времени делали не по ней. Стоило согласовать нашу оценку и оценку стороннего разработчика, проговорив “фичи” и обсудив их заранее.
-
Изначально вести регулярные митапы по промежуточным итогам.
-
Построении четких ГАНТов, по которым заказчик мог бы видеть как сдвигается проект из-за неисполнения сроков по задачам, которые стояли на сотрудниках заказчика.
-
Отсутствии изменения входных условий проекта без изменений договоренности по срокам, даже в случае, если бюджет не меняется и общий объем работ не увеличивается (время на транзакцию не было заложено).
-
Более жестким наблюдением за сохранностью результатов работ. В идеале, всю разработку вести на своих площадках.
-
Отсутствии проблемы с НЕ желанием клиента вникать в детали проекта и брать на себя ответственность за принятые решения. Также у клиента не было желания вникать в ход самого проекта и контролировать работу и успеваемость своих сотрудников.
-
Нормально построенном тестировании.
-
Избегании ссоры с одним из сотрудников клиента.
Часть функционала была описана как идея, а не как задача. В итоге, от части функционала пришлось отказаться и изменить некоторые процедуры, чтобы реализовать основной и важный функционал.
В середине проекта заказчик 2 раза изменил пожелания по системе, с которой должна была бы делаться интеграция. Из-за этого сдвинулись и внутренние, и внешние задачи, а также были изменены принципы интеграции.
Часть результатов работ было потеряно из-за того, что менеджер на нашей стороне не отследил и не проговорил, что именно нужно сделать с тестовой базой 1С, а программист на стороне заказчика ее просто грохнул.
Ранняя диагностика
Любая глобальная проблема вырастает из маленькой ошибки. Чем раньше ты ее заметишь, тем быстрее сможешь исправить, и тем менее катастрофическими будут последствия. Никогда не скрывай проблему. Если у тебя что-то не получается — иди к руководителю. Если член твоей команды пришел к тебе и честно сказал, что он не справляется — не впадай в истерику и не ругай его. В противном случае, он предпочтет в следующий раз промолчать, а проблема всплывет перед дедлайном, когда решить ее будет уже сложно. Если сроки срываются — сообщи об этом заказчику, ведь у него тоже есть обязательства перед кем-то. Вместе вы сможете придумать приемлемое решение.
Заказчику был продан подход SCRUM, заказчик его не понял (не захотел вникать и принимать участие в разработке) и захотел работать по waterfall с точными ТЗ на этап без учета изменений в процессе.
Не использовался метод прогрессивного JPG — весь проект сдавался полностью единомоментно и НЕ беспроблемно. В случае постепенного введения функционала и его поэтапного итерационного тестирования этого можно было бы избежать.
Была потеря связи с командой внешних разработчиков. Фактически, задачи закидывались на оценку, эта оценка принималась за адекватную и на базе этой оценки строился план разработки. После того, как начинали происходить промежуточные факапы по срокам или существенные изменения функционала, были истерики и еще бо́льшие сдвиги по времени.
Частично, проблему удалось решить введением обязательных планерок с исполнителем — 1 раз в неделю команда исполнителей отчитывалась о том, что сделано, о проблемах, обсуждались возможные варианты решения + строился более четкий план работ по проекту на следующую неделю.
Проблема с балансировкой нагрузки на участников проекта.
Что еще нужно сделать по проекту:
-
Корректная настройка метрик
-
выявление необходимых конверсий
-
настройка отслеживания этих конверсий
-
Разработка понятного механизма работы с акциями для клиента и обучение клиента пользоваться ими
-
Настройка регулярных рассылок по скидкам и акциям
-
Добавление внешних способов доставки (транспортные компании)
-
Вывод клиента на Я.Маркет для более широкого охвата
-
Запуск для клиента рекламной кампании
-
Заключение договора на регулярную техническую поддержку
-
Описание полезного для покупателей функционала
-
Настройка более четких бизнес-процессов обработки заказов на стороне клиента (обучение клиента)
-
забор заказа в разных магазинах (когда? как выбрать? кто и когда перевозит? знают ли покупатели?)
-
более четкое описание процедуры забора заказа (когда можно приехать? куда обратиться? где забирать?)
-
продумывание о описание механизмов заказа услуг (как заказать? какие гарантии качества? как можно платить? какие сроки? может ли быть частью заказа?)
-
подарочные карты (как и где купить? как получить? как использовать на сайте?)
-
Автоматизация работы со скидочными картами (в данный момент статус по карте не считается и не обновляется из 1С — нужен обновляемый из 1С HL-блок)
-
SMS-информирование покупателей
-
Переработка раздела “Полезные советы”
-
Разработка калькуляторов количества для карточек товаров
-
Более детальная работа с мета-тегами на сайте. Добавление осмысленных описаний, добавление синонимов