Как сорвать сроки в веб-разработке

Время прочтения: 5 мин
Сложность: норм Просмотров:
Денис Сапожников 27.05.2019

Нет четкого понимания, что конкретно нужно сделать

Камень в огород большинства малых проектов (до 0,5-2млн)

Нет четкого технического задания

Камень полетел туда же.

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

Нет макета

Без адекватного макета невозможна оценка технического задания и сроки в момент исполнения будут «плавать»

Нет прототипа или схематичной зарисовки проекта

По аналогии с отсутствием макета

Нет регламента проведения работ

Нет регламента работ — значит каждый делает что хочет и как хочет, при этом считает себя правым

Нет контрольных точек при реализации проекта

Для мелких проектов достаточно всего две контрольные точки — старт-финиш, для средних и крупных проектов количество ключевых точек легко может достигать 30-50.

Нет конкретного лица принимающего решения

Очень часто со стороны клиента есть нескольких лиц принимающих решение — главный инженер, генеральный директор, руководитель отдела продаж, руководитель отдела маркетинга, состав соучредителей. Если компания вся дружно начнет согласовывать и утверждать каждый момент — … сами понимаете. В данном случае, недостаток информации и ЛПР — в разы лучше, чем их избыток. Опытные разработчики умеют работать в обоих случаях, но большинство объективно лучше справляется в условиях отсутствия ЛПР, нежели их избытке.

Нет конкретных сроков реализации

Сроки «вчера», в течении пары месяцев = никогда

Нет нормального взаимоотношения между заказчиком и исполнителем

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

Ни один договор не заменит нормального отношения друг.

Если для какой-то конкретной задачи для вас критично важны сроки — скажите об этом исполнителю, в половине ситуаций это простое действие спасет от срыва сроков.

Нет договоренности о внесении дополнений вне рамок ТЗ

Исполнители крайне не любят дополнительные работы вне рамок ТЗ, нередко опытные проект-менеджеры со стороны клиента «прогибают» исполнителей нагружая их дополнительной работой. Равно, как и исполнители в рамках проекта любят тыкать носом в ТЗ и посылать лесом даже в незначительных отклонениях.

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

В этом случае вероятность срыва сроков будет существенно ниже.

Нет финансовой дельты при реализации проекта

Ни один проект не может стоить точную сумму, это всегда диапазон стоимости. Очень часто при реализации проекта возникают технические проблемы, требующие дополнительного времени.

Заранее обсудите в каких диапазонах может двигаться эта цена и почему.

Нет заинтересованности в результате у разработчика

Процесс ради процесса. Этим часто грешат компании и специалисты сидящие на ставке или часовой оплате.

Нет предоплаты

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

Нет постоплаты

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

Нет промежуточных оплат в длительных проектах

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

Нет необходимых компетенций у разработчика

Нет контента, необходимого для работы

Нет механизма изменения сроков работы по вине третьих лиц

Хостинг затупил? Регистратор доменных имен накосячил с NS-записями? Дизайнер заболел и не прислал исправленный макет? У копирайтера кошка рожает и он не может прислать текста? Чем больше проект, тем больше действующих лиц, тем больше вероятность срыва проекта.

Нет четких сроков времени реакции на вопросы

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

У заказчика нет понимания, что продукт не производится, а придумывается на ходу.

Мыслительный процесс плохо нормируется. Если вы действительно думаете, что 5 часов в смете равны 5 реальным часам, то Вы сильно ошибаетесь.

Реальный срок выполнения задачи может отличаться в разы в обе стороны.

Если веб-разработчик гуру и знает как решить сложную техническую задачу за 30 минут, а весь рынок может сделать это за месяц, то он не будет ставить вам цифру в 0,5ч, ведь де факта он потратил месяцы и даже годы на изучение вопроса и опыт его имеет определенную цену.

Равно, как и цифра 5ч исполнения, может означать 20 фактических часов работы, если есть технические вопросы, которые требуется изучить для решения или исполнителю необходимо обдумать все.

Нет этапа подготовки к работе

Сюда входит и этап формирования задачи, оценка оптимальных методов решения задачи, подготовка контента и прочие радости жизни

Нет запаса времени на «Эффект неведомой фигни»

Этот коэффициент есть у любого проект-менеджера при оценке абсолютно любой задаче. Если ваш исполнитель никогда не срывал сроки или сроки срываются постоянно, но не значительно — в пределах недели. То все просто — у него крайне высокий коэффициент поправки.

Откуда возникает подобная магия в разработке — отдельная история.

Нет четких санкций за срывы сроков

Вы можете сколько угодно топать ножкой и говорить, какой разработчик негодяй. Но, если в договоре прописано 0,05% пени/неустойки от стоимости задачи в сутки — эти флюиды не принесут никакого результата. Крайне не рекомендую портить отношения с разработчиком, ибо он, как официант. Только официант знает, плюнул кто-нибудь на кухне в тарелку или нет.

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

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

Рано или поздно исчезнут простые работяги, их профессии падут под гнетом автоматизации и нейронных сетей. Следом падут и рядовые разработчики, их заменят SAAS-сервисы. Проект-менеджеры наконец-то окажутся никому ненужными. Останется лишь чернь, бездумно потребляющая контент и безумные изобретатели‑первопроходцы, меняющие мир.

А пока этого не произошло, я буду писать этот блог и стараться давать Вам самую суть разработки, продвижения и управления в IT‑проектах.


P.s. нравится проект?
Ну так помоги развить его - репосты, донат и интересная работа приветствуются

Рекомендую посмотреть

Случайный вопрос

Что бы вы изменили на нашем сайте ********.RU?

Не знаю, для этого мне необходимо посмотреть данные веб-аналитики, данные о рекламных компаниях, данные бизнес-аналитики и информация о том, какая задача сейчас стоит перед бизнесом.

Все, кто будут говорить изменить такую-то кнопочку/переписать текст и так далее — идиоты, играющие в разработчика, а не решающие бизнес-задачи.

Показать больше ответов

Привет, дружок‑пирожок