It-шники и сроки

It-шники никогда не выполняют работу в срок. Но почему так происходит? И можно ли этого избежать?

С кем бы вы не работали: с фрилансером, командой или компанией - ваш проект никогда не будет выполнен в срок. Давайте рассмотрим основные причины:

1. Не начинают проект во время.

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

Как распознать?

Если уточняющие вопросы по ТЗ задают только через неделю, то работа только начинается. Помните, что у каждого разработчика возникают вопросы сразу после прочтения задачи. Нет вопросов - к задаче не приступали.

Как избежать?

Пока вы согласовываете договор, узнайте у разработчиков, на сколько загружена команда и когда они планируют приступить к вашему проекту. Если команда только "освобождается", то заложите больше времени на раскачку, а если уже свободна, то поспешите с подписанием и оплатой.

Договоритесь о дате начала работ. Постарайтесь не привязывать её к дате заключения договора или дате оплаты, потому что если у вас будут проволочки с оплатой или подписанием, то на это время команду займут, и она может к старту работ не освободиться.

Если подписание договора и оплата попадают на середину недели, смело договаривайтесь о начале работ с понедельника!

Будьте настойчивы. Накануне спросите, всё ли идёт по плану. В "день икс" узнайте, удалось ли начать, а вечером или на следующий день — что сделано за первый день.

В первые два дня ваша задача в том, чтобы убедиться, что задача поставлена, разработчик с ней ознакомился, ЗАДАЛ вопросы и начал что-то делать. Как правило, в первые дни разработчик не выдаёт ничего, что можно было бы "пощупать", а, возможно, только думает о том, как лучше реализовать задачу, поэтому не ждите от него какого-то оформленного результата.

2. Отвлекаются на другие проекты

Во-первых разработчики берут на себя гарантийные обязательства по своим проектам. Если называя сроки, они не закладывают 2-3 свободных часа в день на исправление и доработки по старым проектам, то точно опоздают к названному сроку.

Во-вторых, в работе 50/50, велика вероятность попасть в кассовый разрыв. Закрыть который можно, взяв небольшой проект на пару дней, отодвинув ваш большой проект, например.

Как распознать?

Если статус задач не меняется несколько дней, если менеджер не может дать ответ по статусу в течение пары часов, возможно ваш проект на паузе.

Как избежать?

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

3. Возникли технические сложности

Это самый частый и обыденный вариант, если вы делаете нетиповое решение или ваш подрядчик не делал ничего подобного раньше.

Опытный подрядчик заложит в смету риски от 10 до 50 процентов, в зависимости от сложности задачи.

Как распознать?

Обычно разработчики прямо сообщают заказчикам, если что-то не получается.

Как избежать?

Заложить риски на нестандартный проект.

4. Ошиблись с оценкой

Оценка всегда производится на основе предыдущего опыта. Ваш проект разбивается на задачи, а задачи приводятся к похожим задачам из ранее выполненных проектов. Часто при этом не учитываются нюансы конкретного ТЗ. Ещё чаще оценка сроков происходит на основе брифа, а создание ТЗ со всеми уточнениями - один из первых этапов работ.

Как распознать?

Если в процессе работы у вас появляются уточнения и дополнения к ТЗ, то в срок вы не уложились.

Как избежать?

Пересмотрите сроки работ после создания ТЗ. Ведите протокол уточнений и внесения дополнений, подписывайте соглашения об увеличении сроков работ.

Но сроки всё равно увеличатся!? - скажите вы. Да, но вы будете в курсе насколько и это не будет для вас сюрпризом!

5. Слишком долго согласовываются результаты работ

Когда мяч на вашей стороне, разработчик ждёт ответа и старается не отвлекаться. Если вы задержались с ответом, разработчик может переключиться на другой проект. Если вы не отвечаете неделю или две, то вернуться обратно к вашему на следующей день после ответа будет уже проблематично.

А ещё в смету часто не закладывают сроки на правки. А если итераций несколько?

Как распознать?

Если среди этапов работ не указаны сроки на согласование - они не учтены. Если вам некогда заниматься приемкой работ — срок будет нарушен.

Как избежать?

Если вам важны сроки, то 1. Выбирайте надёжного и внимательного подрядчика, который сделает работу с минимальным числом правок. 2. Умерьте свой перфекционизм и сводите к минимуму число раундов правок. 3. Не исправляйте результаты ранее принятых этапов.

На самом деле причин просрочек гораздо больше. Это лишь основные. Мне, например, часто попадались разработчики,у которых случался "переезд" и они пропадали сначала на неделю, а потом навсегда. Но это совсем другая история...

Итак, как же сделать проект в срок?

100% гарантии нет, но всегда можно минимизировать просрочки:

  1. Не ищите подрядчика, который назовёт вам самый короткий срок - это уловка, чтобы продать вам свои услуги. А для вас - лишь самоуспокоение.
  2. Определитесь с минимально достаточным набором функций и опишите его в ТЗ максимально подробно. Сводите неопределенности к минимуму. Дополнительная неделя сбора информации и уточнения ТЗ экономит месяц разработки.
  3. Не добавляйте ничего нового в процессе разработки. Лучше пусть вам в срок сдадут проект по ТЗ, чем просрочат на месяц из-за пары хотелок.
  4. Всегда закладывайте дополнительный срок. Вам сказали будут делать 2 месяца? Заложите 4 (Только разработчику об этом не сообщайте), тогда проект сдадут в срок. Нет 4 месяцев и нужно сделать за 2? Ищите решение, которое можно реализовать за 1 месяц.
  5. Если все совсем плохо, не бойтесь сменить подрядчика.

Пожалуй, всё! Минимальных вам просрочек ;)