Факапы, их причины и решения

Полученные от клиента деньги: ~ 1 200 000 рублей

Потраченные на внешних разработчиков, лицензии: ~ 400 000 рублей

Срок проекта — 12 месяцев.

Время реальных работ с нашей стороны — 4 месяца

Отставание по срокам:

• фактическое — 1 месяц
• юридическое — отсутствует 

Причины факапов

1) Все стремятся сделать задачу ко времени дедлайна, а не тогда, когда могут.

На проекте изначально была существенная проблема с тем, что все задачи имели конечные сроки, но выполнялись они именно ко сроку. В итоге было потеряно очень много времени.

Большой проблемой является то, что все ориентируются именно на дедлайн — то есть на точку времени к которой нужно сделать работу. Но на самом деле, к дедлайну нужно относиться как к точке, в которой эта работа уже должна быть выполнена.

Смотрите, во все временные расчеты мы закладываем запас — на проверки, на исправления и т. д. Что происходит, если задачи выполняются именно к дедлайну — в лучшем случае, мы просто бесполезно теряем все дополнительное время, которое было заложено. В худшем случае мы теряем и его и тратим как минимум столько же дополнительного времени. 

Также, как мне кажется, временных планов должно быть 2: один публичный план — для заказчика, а второй план — для команды.

В план для заказчика можно закладывать страховочное время, а в плане для разработчиков стоит его сокращать.

Для повышения эффективности лучше назначать один дедлайн (без запасов) и несколько промежуточных точек, к которым должны быть достигнуты определенные результаты. Если «промежуточный дедлайн» был сорван — не стоит скрывать этот факт от заинтересованных сторон, и тем более надеяться все наверстать к следующей контрольной точке. Оцените последствия и влияние их на стратегические сроки, продумайте решение (а лучше несколько), затем придите к начальнику (или заказчику) и обсудите с ним возникшую ситуацию и возможные варианты решения.

Такой подход может хорошо работать при условии, что весь проект разбит на четкие и понятные этапы разработки + есть интерактивный ГАНТ, который будет учитывать положительные и отрицательные смещения сроков.  

Я очень рекомендую прочитать книжку “Радикальная прямота” Ким Скотт.

2) Недооценка рисков и времени на задачи по:

• верстке
• программированию
• обратной интеграции OpenCart -> 1C
• интеграции с 1С

Отчасти, была проблема с изначальной оценкой по срокам - мы отошли от нашей типовой сметной оценки и полностью доверились оценке стороннего исполнителя, который не учел нюансов и затянул сроки.

Этого можно было избежать при:

1. Корректной и привычной нам оценке, базирующейся на декомпозиции по скринам до состояния “фич”. Бюджет проекта был посчитан по этой схеме, но оценку по времени делали не по ней. Стоило согласовать нашу оценку и оценку стороннего разработчика, проговорив “фичи” и обсудив их заранее.

2. Изначально вести регулярные митапы по промежуточным итогам.

3. Построении четких ГАНТов, по которым заказчик мог бы видеть как сдвигается проект из-за неисполнения сроков по задачам, которые стояли на сотрудниках заказчика.

Часть функционала была описана как идея, а не как задача. В итоге, от части функционала пришлось отказаться и изменить некоторые процедуры, чтобы реализовать основной и важный функционал.

4. Отсутствии изменения входных условий проекта без изменений договоренности по срокам, даже в случае, если бюджет не меняется и общий объем работ не увеличивается (время на транзакцию не было заложено).

В середине проекта заказчик 2 раза изменил пожелания по системе, с которой должна была бы делаться интеграция. Из-за этого сдвинулись и внутренние, и внешние задачи, а также были изменены принципы интеграции.

5. Более жестким наблюдением за сохранностью результатов работ. В идеале, всю разработку вести на своих площадках.

Часть результатов работ было потеряно из-за того, что менеджер на нашей стороне не отследил и не проговорил, что именно нужно сделать с тестовой базой 1С, а программист на стороне заказчика ее просто грохнул.

6. Отсутствии проблемы с НЕ желанием клиента вникать в детали проекта и брать на себя ответственность за принятые решения. Также у клиента не было желания вникать в ход самого проекта и контролировать работу и успеваемость своих сотрудников.

7. Нормально построенном тестировании.

8. Избегании ссоры с одним из сотрудников клиента. 

Ранняя диагностика

Любая глобальная проблема вырастает из маленькой ошибки. Чем раньше ты ее заметишь, тем быстрее сможешь исправить, и тем менее катастрофическими будут последствия. Никогда не скрывай проблему. Если у тебя что-то не получается — иди к руководителю. Если член твоей команды пришел к тебе и честно сказал, что он не справляется — не впадай в истерику и не ругай его. В противном случае, он предпочтет в следующий раз промолчать, а проблема всплывет перед дедлайном, когда решить ее будет уже сложно. Если сроки срываются — сообщи об этом заказчику, ведь у него тоже есть обязательства перед кем-то. Вместе вы сможете придумать приемлемое решение.

Заказчику был продан подход SCRUM, заказчик его не понял (не захотел вникать и принимать участие в разработке) и захотел работать по waterfall с точными ТЗ на этап без учета изменений в процессе.

Не использовался метод прогрессивного JPG — весь проект сдавался полностью единомоментно и НЕ беспроблемно. В случае постепенного введения функционала и его поэтапного итерационного тестирования этого можно было бы избежать.

Была потеря связи с командой внешних разработчиков. Фактически, задачи закидывались на оценку, эта оценка принималась за адекватную и на базе этой оценки строился план разработки. После того, как начинали происходить промежуточные факапы по срокам или существенные изменения функционала, были истерики и еще бо́льшие сдвиги по времени.

Частично, проблему удалось решить введением обязательных планерок с исполнителем — 1 раз в неделю команда исполнителей отчитывалась о том, что сделано, о проблемах, обсуждались возможные варианты решения + строился более четкий план работ по проекту на следующую неделю.

Проблема с балансировкой нагрузки на участников проекта.

Что еще нужно сделать по проекту:

1. Корректная настройка метрик

1. выявление необходимых конверсий

2. настройка отслеживания этих конверсий

2. Разработка понятного механизма работы с акциями для клиента и обучение клиента пользоваться ими

3. Настройка регулярных рассылок по скидкам и акциям

4. Добавление внешних способов доставки (транспортные компании) 

5. Вывод клиента на Я.Маркет для более широкого охвата

6. Запуск для клиента рекламной кампании

7. Заключение договора на регулярную техническую поддержку

8. Описание полезного для покупателей функционала

9. Настройка более четких бизнес-процессов обработки заказов на стороне клиента (обучение клиента)

1. забор заказа в разных магазинах (когда? как выбрать? кто и когда перевозит? знают ли покупатели?)

2. более четкое описание процедуры забора заказа (когда можно приехать? куда обратиться? где забирать?)

3. продумывание о описание механизмов заказа услуг (как заказать? какие гарантии качества? как можно платить? какие сроки? может ли быть частью заказа?)

4. подарочные карты (как и где купить? как получить? как использовать на сайте?)

10. Автоматизация работы со скидочными картами (в данный момент статус по карте не считается и не обновляется из 1С — нужен обновляемый из 1С HL-блок)

11. SMS-информирование покупателей

12. Переработка раздела “Полезные советы” 

13. Разработка калькуляторов количества для карточек товаров

14. Более детальная работа с мета-тегами на сайте. Добавление осмысленных описаний, добавление синонимов