IT Rules: как построить правильный процесс

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

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

ТЗ должно быть

В начале моей карьеры большинство моих клиентов были мои знакомыми или знакомыми моих знакомых. Довольно типичной была ситуация, когда при старте проекта клиенты отказывались от детальной проработки ТЗ (да и вообще от самого ТЗ как такового). Сразу скажу, что это очень плохая практика. Даже если вы в отличных отношениях с заказчиком и полностью ему доверяете, а он вам — все пункты необходимо фиксировать и подробно описывать. Ведь даже понимание одних и тех же терминов может кардинально различаться у различных участников проекта. Так мне доводилось быть на встрече, на которой несколько часов обсуждалось только основное понимание терминов предметной области. Разработка при этом ещё даже не начиналась.

Даже плохое ТЗ лучше, чем отсутствие какого-либо.

Дополнительные работы — только после подтверждения клиента

Бывает так, что после подписания, согласования сроков и подписания договора (в данном случае речь идёт о формате fixed price) спустя время команда понимает, что объем необходимых работ несколько больше. Чем раньше команда и руководитель проекта это поймут, тем лучше.

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

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

Оценка сроков

Всегда делайте запас по срокам. Оценку сроков, которую делает разработчик, желательно умножать на 2.5, дизайнер — от 1.5 до 3.0.

Причём в большинстве случаев, чтобы успеть до дедлайна, нужно будет очень постараться.

Письмо по итогам встречи

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

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

Предметная область важнее всего

Во всех проектах соблюдайте приоритет: предметная область → архитектура → административные задачи.

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

Решение создается в первую очередь для клиента, а не для программиста или администратора.

Open Source надо использовать с умом

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

Не стоит сразу писать платформу

Лучше решать поставленную задачу. Многие разработчики (и я в том числе) иногда страдают этим же подходом, мгновенно стремясь написать универсальное решение для всего и сразу. Не стоит этого делать. Лучше решить конкретную задачу и получить результат. Потраченное на создание универсального решения время может не окупиться и часто не будет востребовано в будущем. Кроме того, чем универсальнее решение, тем чаще оно получается сложным и ограниченным в использовании.

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

Всегда используйте dev, staging, production environments

Даже если вам кажется, что проект маленький и всегда все можно поправить на сервере клиента, делайте тестовое окружение, окружение для разработки и рабочее окружение. Тем более, что современные сервисы и платформы позволяют построить подобный процесс даже без привлечения дорогостоящих DevOps специалистов. Так, например, связка GitHub/Bitbucket + Azure App Services позволяет настроить при разработке веб-приложения процедуру Continuous delivery всего за 15 минут. Достаточно создать три ветки (dev, staging, production) в репозитории и создать три сервиса в Azure App Services, для каждого из которых будет настроена своя тарифная модель, параметры масштабирования и привязаны различные доменные имена.

Потратив довольно мало времени, в будущем вы сэкономите много времени и нервов.

Лучше применять готовый продукт, чем писать свой

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

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

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

Явные признаки того, что лучше купить и внедрить, чем писать:
— Существует продукт, который покрывает предполагаемый сценарий использования;
— Существует продукт, который покрывает предполагаемый сценарий использования после определенной конфигурации;
— Существует несколько продуктов, которые при взаимодействии и интеграции покрывают предполагаемый сценарий использования;
— Существует продукт, который можно расширить определенным функционалом (дописать модуль для CRM), и после этого он покроет сценарий использования.

Когда есть смысл писать свой:
— Человек, принимающий решение, точно знает, почему он начинает разработку, и точно понимает цели и задачи проекта;
— На рынке нет продукта, который мог бы реализовать требуемую функциональность;
— У компании достаточно финансов, чтобы не только длительное время инвестировать в продукт, но и заниматься впоследствии его поддержкой;
— Вы — стартап, и для вас работают совершенно другие критерии.

Экономьте время

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

Дело было давно. Пришел как-то раз к барину работник и спрашивает:
— Здравствуй, барин, вопрос меня мучает. Я на тебя работаю, много сил трачу. Платишь ты мне в день по рублю. А Василию в тот же день — по пять рублей. Отчего такая несправедливость?
— Разумный вопрос, Федор, — отвечал барин, — отвечу я тебе на него. Только сперва сходи-ка посмотреть — видишь, везут мимо моего двора что-то. Узнай, что?
Сказано — сделано.
Возвращается мужик к барину и отвечает:
— Рыбу везут.
— Это хорошо, рыба нам нужна, — говорит барин, — а свежая ли, или соленая?
— Не знаю, — отвечает Федор.
— Ну, сходи узнай.
Сбегал мужик, вернулся:
— Свежая, с утра пойманная.
— Свежая — это хорошо, надо брать. А почем берут, не сказали?
Снова бежит мужик к возчикам, возвращается:
— По десять рублей просят.
— Дорого берут, дорого. Сторговаться можно ли?
— Сейчас с узнаю, барин — сбегал мужик снова, возвращается и докладывает:
— Сторговались по семь рублей!
Хорошо — говорит барин. Зовет Василия:
— Узнай Василий, что там везут мимо нашего двора — Василий идет к повозкам и возвращается спустя десять минут.
— Везут рыбу, свежую. Продают за десять рублей. Нам рыба нужна, потому я сторговался до семи рублей и взял нам целый воз.
— Ну что, понимаешь теперь, — говорит барин — почему тебе я плачу по рублю, а Василию по пять?