11 советов, как делать проекты и не сдохнуть

То, что проектный бизнес - это жесть, знают все. Просчитать реальную себестоимость и сроки нужно до выполнения задачи. И от того, насколько скромной она получилась, часто зависит вероятность получения контракта. А корректировки и пожелания возникают после. Или в процессе. И нужно одновременно уложиться в срок, заработать и получить лояльного клиента, который продолжит размещать заказы и рекомендовать друзьям.

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

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

Несколько десятков тематических картинок, куча крутых историй, советы бывалых… Все это идет лесом, когда появляется хоть один минимальный аргумент «вот в этом проекте, тут все просто и понятно, давайте не будем делать ТЗ». Когда ресурс времени/денег ограничен, может казаться, что писать ТЗ не нужно или не рационально. Есть подходы (методологии), которые предполагают работу без подробных техзаданий. Так вот, это - иллюзия.

Если ваш проект разбит на задачи (Канбан), то у каждой задачи должно быть подробное, однозначное и непротиворечивое описание. Если разбит на спринты (Скрам), то у вас должен быть беклог с задачами, которые (см выше) опять же должны быть описаны. Если сложить описание всех задач в большом проекте, получится ТЗ на несколько десятков страниц. Так вот, в классическом Faterfall 1 (один) день, потраченный на разработку ТЗ экономит 1 (один) месяц на сдаче-приемке проекта.

Подробо расписанное ТЗ может как увеличить, так и сократить объем работ, планируемый на преселле. Соответственно, в Договоре вам нужен пункт о том, что цена может быть пересмотрена после согласования ТЗ.

И да, я за то, чтобы писать ТЗ после дизайна. Потому что в этом случает туда намного проще и точнее закладываются описания всех визуальных эффектов и работы элементов проекта.

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

Иногда сложные задачи поступают на этапе пресела. Иногда в процессе проекта. Так вот, оценивать задачу должен программист. Есть два подхода. В первом задачу оценивает тот, кто будет ее делать. И если не уложился в свою оценку, то «лишнее» не оплачивается.

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

Доводилось сталкиваться с тем, что либо заказчик просит, либо исполнитель предлагает безлимитное количество правок в дизайн. «Правим до согласования», примерно так. Лично меня от этого отучил заказчик, получивший 52 (пятьдесят две) версии макета главной страницы! Как итог, я посчитал, что дешевле вернуть ему оплату, чем дальше работать по проекту. Проблема тут одна - рентабельность. При бюджете X мы можем потратить часы Y на задачу. И если объем работы превышен на 20% и более, то исполнитель на проекте не зарабатывает. А если на 30%, то начинает терять. То есть попадает в ситуацию, когда «дешевле не работать».

По-этому после внесения определенного количества (обычно 3-4) правок, макет считается принятым.

Тут все просто. Если на присланную работу нет ответа в определенный срок (от 3 дней до недели обычно), то работа считается принятой. Это не наша придумка, это положение Гражданского Кодекса. Попытка внести в договор иное, является ошибкой как с точки зрения управления проектом, так и и точки зрения законодательства.

Тут вместо объяснения расскажу 2 реальные ситуации.

Менеджер проекта приносит заказчику макеты. - Все нравится (почти не глядя) - Да - Подпишите акты - Пожалуйста - Теперь подпишите сами макеты

- О! Если мне надо их подписывать, то я их тогда посмотрю

Вторая ситуация

Менеджер на стороне клиента согласовал с нами одну версию макета. А с директором другую. «Подлог» вскрылся только на готовом проекте. Пришлось переделывать.

Как итог. Подписывайте не только акт за работу, но и саму работу. Дизайн, текст ТЗ, скрин-шот верстки. Сэкономит кучу сил и времени.

Тут возможны две проблемы. Первая: тот, кто будет заполнять сайт, может проигнорировать инструкции по работе с ним и банально его сломать. А чинить вам и за свои деньги. И второе - мы создаем «на той стороне» соблазн получить проект «за полцены». А уж советчиков, которые расскажут, что именно так и надо поступить, и вообще эти жулики разработчики должны работать бесплатно, уверяю, вокруг ЛПР-а всегда найдется тысяча.

Все просто: сроки автоматически (по договору) продлеваются на время согласования выполненной работу. Почему так? Представим себе, что на каждый этап работы мы ждем ответа по 3 дня (и еще 2 исполняем то, что указано в ответе). Получается, что одна итерация правок занимает рабочую неделю. В каждом этапе работ разрешено 3-4 итерации правок. В проекте 4-5 этапов. Получаем продление сроков на 20(!) недель без единого дня задержки на стороне исполнителя. Хотите платить неустойку за полгода опозданий по срокам? Нет? Тогда пишите «Сроки исполнения работ по договору автоматически продлеваются на время внесения правок».

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

Если вы из-за ошибки в оценке, из-за загруженности или из-за предыдущего пункта опоздали по срокам, то.. смело платите за это штраф и работайте дальше. Почему так? Потмоу что как только вы согласитесь бонусом за это выполнить хоть одну задачу, вам пиздец. Задача удлиннит сроки. За еще раз выросшее опоздание вы согласитесь сделать еще одну доп работу и так можно делать годами. Как итог, испортить отношения с заказчиком и перестрелять друг друга на дуэли (словесной).

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

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

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

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

Но в любом ином случае взяться решать бесплатно, значит признать себя виноватым в проблеме. И автоматически поставить заказчика в позицию «мой исполнитель плохой - исправляет, исправляет и никак не исправит». Так вы получите разом и испорченные отношения и убыточный проект. А могли бы получить хорошие отношения и прибыльный проект.

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

А тем, кто дочитал до конца, бонусные двенадцатые грабли о работе одного специалиста над несколько проектов. Расскажу их в виде анекдота: Решили открыть в Одессе публичный дом для иностранных моряков. В горком пригласили тетю Песю с Молдаванки, известную в дореволюционной Одессе бандершу, и предлагают ей возглавить новое учреждение. Ей сулят всяческие блага. - Нет, - говорит тетя Песя, - знаю я ваши порядочки. Десять коек - для горкома, двадцать - для обкома, органам - по потребности. Весной вы будете моих девочек дергать в колхоз на посевную, осенью - на уборочную. А тетя Песя ложись и выполняй план?