×Закрыть

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), и после этого он покроет сценарий использования.

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

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

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

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

LinkedIn

31 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Наболевший вопрос: что делать, если клиент и разработчик не прояснили часть терминологии, и даже при составленных договорах и техзадании остаются принципиальные вопросы «а кто будет делать Х»? Что примечательно, клиент рассчитывает за свои деньги получить готовый продукт, а разработчик считает, что контент, например, к готовому продукту не относится. Как спасать проект? :(

1 путь конструктивный: Сеть и обсудить терминологию, опеределиться с тем, что сделано в соответсвие с обсужденным, что нет. Клиенту оплатить дополнительную работу.
2 пусть неконструктивный. Обосрать друг друга на ДОУ.

Спасибо за лаконичную и полезную статью.
Хотелось бы уточнить, что имеется ввиду под ТЗ (общие требования к результату, терминология или детальное описание всех модулей, возможностей и тп) .
ТЗ больше подходит под waterfall модель процесса разработки. А что если работать по agile, где требования могут динамично менятся , или их попросту нет , что часто свойственно стартапам (и не только). В таком случае ТЗ может стать баластом. Или нет?)

Вот поэтому-то 90% стартапов и не взлетают :)

Чесно кажучи, я дуже сумніваюсь, що 9 із 10 стартапів не злітають через відсутність ТЗ :)) Особливо , якщо немає підрядчиків, або ще когось, кому треба пояснити , що треба зробити і , хто взагалі не розуміє предметної області.

Вот-вот ТЗ это и есть письменно зафиксированные цели проекта.
От них пляшет и найм и сроки и маркетинговая модель.
Если их нет — все дальнейшие шаги бесполезны.

В мене враження, що ви за своє життя не працювали в жодному стартапі...
Маркетингова модель не пляше від ТЗ. Скоріше навпаки, спочатку йде маркетинг, потім вже реалізація. Строків в стартапі немає. Зазвичай це або «на вчора», або «на позавчора». Сиплються стартапи через те, що вони роблять продукт, який нікому не потрібен.

В мене враження
Ошибочное, насмотрелся. И здесь и там.
Маркетингова модель не пляше від ТЗ.
Еще как пляшет. ТЗ отвечает на самый клавный маркетинговый вопрос “чем отличается наш продукт уже присутсвующих на рынке” и вот тут половина великих инноваторов скисает. Они не могут это сформулировать.

От тому й скисають стартапери, що думають, що пляше...

Вони не злітають за іншою причиною

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

Якщо працювати по Agile, то ТЗ — це епіки і юзер сторі.

Андрей, где можно посмотреть пример грамотно составленного ТЗ для создания программного продукта. И что почитать про основные принцыпы создания правильного ТЗ?
Спасибо!

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

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

Василий — холоп крепостной — барин вообще может ему не платить равно как и сам Василий никакой чисто технически экономической хозяйственной ответственности в этих операциях не несёт.

А разница-то где? )))

«ошибка выжившего»

не спорю, дополняю со своего опыта.

страдания насчет ТЗ — это когда fixed price проект. тогда да. в остальных случаях — не обязательно иметь полную картину на момент старта.

а с оценкой времени: еслина старте пытаетесь оценить в целом, лучше все же не дробить на задачи, а оценивать грубо сразу в днях-неделях. почему-то получается точнее, чем декомпозиция + оценка каждого мелкого куска("ошибка" накапливается?). а еще время от времени делать ревью оценок времени — в процессе работы могут как реально крутые неожиданности полезть, так что-то и легче может оказаться.

А если рыба не нужна?

Все верно, но принятие решения барин должен был оставить себе.

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

административные задачи могут вполне быть потребностями бизнеса

здесь нет линейной цепочки приоритетов, есть задача и есть ее решение

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

Сразу скажу, что это очень плохая практика
Погана практика для того, хто грає роль «рук» в проекті. Тоді так, це біль та страждання. Якщо ви берете на себе роль «голови», то ТЗ вам може бути й не потрібно. Але, це не значить, що замовник не приймає участі в проекті. Ні, він виконує роль уточнювача ТЗ якщо ви або замовник з певних причин щось прогавили.
Краще в такій ситуації виконувати розробку через прототипи. Саме прототипи показуються замовнику та розповідається їх призначення. Задача замовника — підтвердити, що прототип підходить під бізнес-процес.

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

спецификация того, что должно быть сделано
Всі ТЗ описують одну й ту саму задачу: автоматизація процесу(-ів).

Не все.
ТЗ на графический дизайн вообще не касается автоматизации.

Дизайн як мистецтво — так. А от якщо дивитися на дизайн програмного продукту, то тут тим паче йде мова про автоматизацію процесу.

Такое ощущение, что я знаю вашего бывшего сотрудника)

Подписаться на комментарии