Получился очень длинный пост. Чукча не писатель, так что перейдем к сути дела. Тапками кидайте: конструктивную критику воспринимаю хорошо.
Для ЛЛ: Хорошее ТЗ это хорошо, можно с простым ТЗ, можно без ТЗ. Важно уметь договариваться.
Всем привет. Меня зовут Евгений Ковалевич. Я генеральный директор компании Skillline.
Мы запускаем циклы статей и подкастов про корпоративную разработку веб-проектов.
Первым циклом будет серия статей про техническое задание: зачем и в каких случаях оно необходимо, как разрабатывается и применяется в ходе реализации проекта, какой должна быть структура и как написать техническое задание.
Сегодняшняя статья посвящена теме необходимости технического задания.
И прежде чем ответить на этот вопрос определимся с тем, какие заказчики заказывают проекты, и какие исполнители их реализуют.
Определим следующие категории:
Малый бизнес (МБ) — характеризуется тем, что у компании еще нет сильно развитой инфраструктуры и отсутствует экспертиза в реализации ИТ-проектов (тут я имею в виду, что полностью отсутствует ролевая модель с выделенными специалистами по маркетингу и ИТ).
Средний бизнес (СБ) — характеризуется монолитной инфраструктурой (работы по развитию инфраструктуры в компании не постоянны, а по потребностям). Также в среднем бизнесе присутствует понимание рынка заказной разработки, но отсутствует углубленная техническая экспертиза (топ-менеджмент с опытом, но без штата специалистов имеющих углубленные понимания процессов реализации проекта).
Крупный бизнес (КБ) — характеризуется постоянно развивающейся инфраструктурой и наличием профильной экспертизы внутри компании и распределенной по отделам ролевой моделью.
Стартапы (С) - нередко характеризуются наличием углубленной технической экспертизы, но отсутствием инфраструктуры (оно и понятно, поскольку они чаще всего приходят с деньгами за развитием инфраструктуры и созданием технологического решения).
Хочу обозначить два момента:
1. Под экспертизой подразумевается совокупность софт-скилов и технических компетенций
2. При обозначении распределенной ролевой модели, я подразумеваю, что в компании есть отдельные топ-менеджеры по направлениям маркетинга и ИТ, и соответствующие отделы с профильными специалистами.
В данном перечне отсутствуют типы заказчиков, которых я больше отношу к частным случаям будь то:
Заказчики, желающие сотрудничества по разработке продукта, не имея бюджета (просящие в долг).
Госкорпорации и государственный сегмент.
Крупные компании, самостоятельно работающие с исполнителями по модели аутстаффинга.
Виды исполнителей
Небольшое отступление, бус-фактор (Bus factor) — это параметр, определяющий сколько человек должен потерять исполнитель, чтобы проект не имел возможности и смысла дальнейшей реализации с данным исполнителем. Чем данный параметр выше, тем лучше.
Фрилансеры (Ф) — характеризуются формой организации (чаще всего это самозанятые, либо ИП) и уровнем компетенций, который определим как средний, поскольку рынок перенасыщен низкоквалифицированными кадрами, а высоко компетентные специалисты уходят в найм, либо развиваются в открытие своего собственного дела.
Ролевая модель проекта закрывается только посредством кросс-функциональности отдельных специалистов. Самый низкий бус-фактор среди всех исполнителей.
Лоукостеры (Л) — характеризуются отсутствием экспертизы у подавляющего числа специалистов в компании, и в то же время очень хорошими компетенциями в сопровождении клиентов, и в продажах. Ролевая модель закрывается отдельными специалистами, но при этом узкопрофильные эксперты отсутствуют.
Бус-фактор максимально высокий из всех видов исполнителей на рынке.
Бутик (Б) — характеризуется высокой экспертизой у всех участников реализации проекта, но при этом ограниченным объемом ресурсов. Ролевая модель закрывается отдельными экспертами, но присутствуют случаи частичного сопряжения ролей.
Бус-фактор низкий.
Фабрика (ФБ) — характеризуется уменьшением экспертизы (в сравнении с бутиком) за счет размытия компетенций при увеличении штата.
Кросс-распределение обязанностей отсутствует.
Бус-фактор высокий.
Гибридный Бодишоп (БШ) — характеризуется очень большим объемом доступных ресурсов и системой обособленности команд разработки. Бус-фактор компании выше чем у фабрики, но для отдельно взятой команды ниже. При этом компетенции аналогичного уровня, что и у фабрики.
Небольшая ремарка относительно «гибридного бодишопа». Бодишоп — это компании работающие по модели аутстаффинга. В России это не так распространено как на западе. У нас крупные компании такого формата позиционируют себя как разработчики проектов на заказ, предлагающие аутстаффную модель сотрудничества.
Мы определили виды заказчиков и исполнителей
Типы технического задания
Теперь перейдем к классификации типов технического задания.
Однозначно написать техническое задание, которое будет полноценно использоваться при реализации проекта, это большая работа. Потому разделим техническое задание на два типа:
Необходимое для формирования юридических рамок (Юридическое ТЗ).
Включающее предыдущее и достаточное для определения конечной формы реализуемого проекта (Полное ТЗ).
Юридический вариант ТЗ имеет один неоспоримый плюс, можно быстро приступить к работе и углубиться в сотрудничество.
Первый тип ТЗ можно описать двумя крайними видами:
Жесткое (шаг влево, шаг вправо — допы): такая форма применяется у лоукостеров и фабрик с готовыми решениями. Они работают с определенной аудиторией заказчиков для которой реализация проекта идет рука об руку с экономией. Поскольку такие проекты очень сильно похожи друг на друга, то у исполнителей уже есть шаблон ТЗ в который необходимо вписать пожелания заказчика, а функциональность, используемая при реализации проекта, будет типовой.
Мягкое: такая форма ТЗ удобна для фрилансеров и бутиковых агентств, так как сохраняет творческую свободу и размывает ответственность за реализацию проекта между заказчиком и исполнителем. Но это обоюдоострый меч: для обеих сторон наличие только юридических рамок переносит ответственность за конечный результат в плоскость коммуникаций, договороспособности и управления ожиданиями друг от друга.
Теперь рассмотрим второй тип — Полное ТЗ, которое дает ярко выраженное представление для всех сторон о конечном результате.
Может показаться, что такое техническое задание - это идеал желаний для любой компании, но тут возникают свои подводные камни строгой работы по техническому заданию. Мнение людей по одному и тому же вопросу, по которому был достигнут компромисс, может изменяться, а это, в свою очередь, накладывает обязательство поддерживать такое техническое задание в актуальном состоянии на протяжении всего проекта, что несет дополнительные затраты на реализацию проекта, но может уберечь от расхождения ожиданий и действительности при достижении цели. С другой стороны, техническое задание может быть достаточно информативным чтобы у проекта был описан путь реализации, но оставалось место для гибкости принятия решений.
Обозначим данные два вида технического задания как строгое и творческое:
Строгое техническое задание подходит для всех исполнителей, для которых проект является просто возможностью увеличения нагрузки на компанию. И это очень хорошо для определенного вида проектов, и для заказчика, у которого есть хорошая техническая экспертиза. Эффективнее всего такое техническое задание для работы с фрилансерами, фабриками и гибридными бодишопами.
Для лоукостеров это приемлемый вариант, поскольку они могут позволить себе увеличение объемов работы для компенсации неточности реализации, при этом не выходя за рамки бюджета, что они спокойно делают за счет финансовой модели реализации проектов. Для бутиковых компаний такое ТЗ накладывает ограничения, в связи с которыми они теряют свое основное конкурентное преимущество - влиять своей экспертизой на проект.
Творческое техническое задание — это форма, в которой у опытной команды есть возможность реализовать весь свой потенциал и полноценно внести в проект свою экспертизу.
При таком формате у заказчика есть возможность апеллировать ТЗ при определении уровня качества реализации, а у команды появляется ответственность провести согласование всех творческих решений и реализовать проект с обозначенным путем реализации.
Такое ТЗ подойдет для сотрудничества с фрилансерами, бутик-компаниями и фабриками.
При работе с гибридным бодишопом возникнут вопросы по отношению к качеству креатива полученного от такой компании: заказчик получит высокий уровень качества реализации кода, но визуальная составляющая будет определяться специализацией исполнителя и может быть ситуация, при которой у конечного исполнителя, работающего с проектом, не будет опыта работы с нишей заказчика.
Для лоукостеров такое ТЗ как точка роста, если у исполнителя есть выделенная команда для таких проектов. В противном случае заказчик может не получить того уровня качества, которое ожидает.
Обобщим: есть 4 вида заказчиков, есть 5 видов исполнителей и 4 вида технического задания.
Как определить какое техническое задание необходимо для проекта
Для начала надо понять: нужно ли для проекта полноценно сформулированное ТЗ, и надо ли на это тратить ресурсы или можно обойтись юридическим, либо вовсе работать без него.
С каким бы из исполнителей не работал заказчик, если бюджета на техническое задание нет, то этим можно косвенно определить вид проекта как типовой, и тогда необходимо выбрать с каким из исполнителей заказчик сможет работать на основании юридического технического задания.
В случае если денег нет совсем, то можно работать с лоукостерами или фрилансерами. С кем именно работать - лучше определиться, основываясь на наличии экспертизы со стороны заказчика.
Если заказчик понимает как устроены все процессы реализации проекта и может ими управлять, то лучше к реализации проекта привлечь фрилансеров.
Соответственно, если у заказчика отсутствуют необходимая экспертиза, лучше выбрать лоукост компанию.
Что при этом делать если бюджет есть, но он ограничен и строго регламентируются его расходы (очень актуально для грантовых проектов) или когда нет времени на реализацию технического задания в связи с малыми сроками на реализацию проекта (например, у заказчика через 3 месяца запуск рекламной компании)? В такой ситуации можно работать с бутиковой компанией: да, заказчик оплатит дороже, чем если бы обратились к фрилансерам или лоукостерам, но в конечном итоге получит более качественный результат вследствие большей экспертизы. Плюс, реализация качественного проекта для бутиковой компании - вопрос репутации (поскольку большая часть таких компаний работает, в основном, на эффекте сарафанного радио, и прямом выходе на клиентов).
При этом надо понимать о каких цифрах идет речь в вопросе выделения бюджета на техническое задание.
Юридическое ТЗ можно реализовать без бюджета. В таком формате в первую очередь заинтересован исполнитель, который готов работать с бюджетом заказчика.
В случае, если мы говорим о крупном проекте стоимостью от нескольких миллионов рублей, то я рекомендую выделять около 10% доступного бюджета на написание ТЗ. Чем объемнее проект в трудозатратах, тем больше должно быть проведено подготовительной работы, начиная с текстового описания и заканчивая маркетинговыми исследованиями и разработкой прототипов.
В случае, когда бюджет на реализацию проекта выделен большой, однозначно надо писать полноценное ТЗ, а не ограничиваться только юридическим.
Если заказчик не может это сделать самостоятельно, есть два варианта:
Доверить данную задачу консалтеру, который может в последствии на себя взять работы по управлению проектом со стороны заказчика.
2. Доверить написание технического задания исполнителю, которого заказчик выбрал для дальнейшей реализации проекта.
Но тут есть риск: когда исполнитель понимает, что он будет являться подрядчиком по проекту, качество реализуемого ТЗ может упасть, и если заказчик не обладает технической экспертизой, он может оплатить юридическое ТЗ по цене полного.
Что делать заказчику, чтобы потратить деньги выделенные на проект эффективно, если есть понимание, что это крупный нестандартный проект:
1. Не работать с лоукостерами. Основа работы с ними в их подходе к рынку: они не накапливают экспертизу для реализации крупных проектов (все банально - чем больше сотрудник иполнителя понимает и умеет, тем дороже он стоит для исполнителя, что в свою очередь влияет на стоимость реализации проекта для заказчика: им невыгодно накапливать такую экспертизу для работы с крупным бюджетом в случае, если они работают в сегменте небольших лоукост проектов).
Заказчик может попробовать самостоятельно собрать команду для своего проекта если внутри есть управленческая и техническая экспертиза, и заказчик имеет время для поиска и формирования команды. Плюс такого подхода в некоторых формах владения интеллектуальной и авторской собственностью разрабатываемого проекта, в том что заказчик может за меньшие деньги получить намного больше трудоресурсов для своего проекта, но вместе с тем он берет на себя все риски по реализации проекта, простою сотрудников. При этом, ему надо прогнозировать какой рентабельной нагрузкой он обеспечит сотрудников по завершению проекта. Минус такого подхода в том, что экономия такого характера не всегда выгодна (пример: выплачивая специалисту на руки зарплату в 120 тысяч, заказчик сверху еще платит 59 тысяч налогов, и в итоге, в годовом обороте это 2 330 000 расходов), а заказчик при этом имеет доступ к экспертизе только внутренних сотрудников.
Может появиться соблазн заменить работников в штате на фрилансеров для доступа к большей экспертизе, и большей экономии, но это еще больший риск для заказчика который попробует реализовать крупный проект таким способом. Надо уметь найти, привлечь и уметь управлять такими сотрудниками. При этом, хочу сказать, что за все время моей карьеры, я видел ИТ-компании и заказчиков, которые привлекали фрилансеров на проекты, видел несколько успешных кейсов привлечения их на разовые работы, и намного больше кейсов, когда проекты полностью проваливались при неумении управлять и прогнозировать работу с такими людьми, хотя работы там было на пару сотен часов).
У нас остается три варианта не учтенных исполнителей для реализации крупного нестандартного проекта:
Работа с бутиковой компанией имеет свой риск ввиду ограниченности ресурсов исполнителей для проекта. Чтобы это нивелировать необходимо максимально спрогнозировать потенциальные точки расширения со стороны заказчика, поскольку в случае, если это не будет учтено, то проект может выйти из под контроля (так бывает часто, поскольку в ходе реализации у заказчика просыпается аппетит, а формат бутика в том, что там нравится подход к работе, и сложно остановиться, когда у компании при этом есть бюджет. Но правда такова, что бутик не может уйти в работу с одним заказчиком на годы, и не может поставлять высококвалифицированные кадры, забирая их с рынка (формат компании не такой)).
Работая с фабрикой, имеется риск реализации проекта только частично исполнителем, а частично субподрядчиками, работающими под этой фабрикой. По факту заказчик может попасть в ситуацию, когда вследствие такой работы получит меньше ресурсов на реализацию проекта, чем предполагает его бюджет. Чтобы избежать этого необходимо в договоре прописать запрет на привлечением третьих лиц к реализации проекта. Если исполнитель не готов подписывать такой пункт, то заказчик явно будет переплачивать за цепочку субподрядов.
Работа с гибридным бодишопом, в целом похожа на ситуацию работы с фабрикой, но в данном случае заказчик получит отдельно выделенную команду под проект. В целом рисков меньше, но и проект может оказаться не приоритетным для такого исполнителя. В текущей рыночной ситуации, когда бодишопы ориентируются на закрытие потребностей цифровых гигантов, заказчик может столкнуться с ситуацией, когда будет дедлайн на работу с тем или иным специалистом.
Подведем итоги:
Когда необходимо написание полноценного технического задания:
когда на стороне заказчика нет компетенций по реализации проекта .
когда заказчик выделяет большой бюджет на проект.
когда в проекте не предполагается интенсивного участия заказчика в ходе реализации проекта.
Когда можно использовать юридическое ТЗ:
И техническое задание не нужно:
когда со стороны заказчика присутствуют высокие компетенции и ресурсы на сопровождение реализации проекта.
когда заказчик формирует внутреннюю команду разработки, где надо выстраивать процесс и писать спецификацию, а не ТЗ.
В конце хочется напомнить, что разработка любого проекта это, в первую очередь, коммуникация между людьми. Учитесь договариваться с теми, с кем вам хочется работать.
Ну и по традиции пикабу, что бы меня было за что хейтить), выкладываю ссылку на телеграм канал https://t.me/skillline_ru. Там я опубликовал подкаст по данной теме.
И бонусом: если у вас есть техническое задание, и вам нужно проконсультироваться, я готов вам бесплатно помочь (под помощью подразумевается: вычитать ваше ТЗ, определить его слабые и сильные стороны, ответить на ваши вопросы). Для этого пишите в телеграмм @EKovalevich
