Представим, что нужно узнать стоимость и сроки разработки, но исполнитель не торопится озвучивать предложение, дает большие «вилки», а для точности просит ТЗ, хотя ему уже все предоставили. Разбираемся, почему так происходит и что с этим делать.
Понимание задачи
Прежде чем взяться за выполнение любой задачи, ее нужно тщательно проанализировать. Если постараться вместить анализ в простой алгоритм, то выглядеть будет вот так:
Задача. В чем ценность?Решение. Как выполним?Работоспособность. Решение соответствует задаче?Результат. В каком виде ожидается результат?Срок. Когда нужен результат и почему?Ограничения. Что может повлиять на работу?Референсы. Делал ли кто-то что-нибудь подобное? Как мы можем это применить?
Этот алгоритм подходит для любой ситуации, даже самой мелкой бытовой:
Задача: украсить комнату картиной;Решение: вбить в стену гвоздь;Работоспособность: гвоздь выдержит картину;Результат: картина висит на стене и радует глаз;Срок: успеть до прихода гостей на выходных;Ограничения: нужно сделать днем, чтобы не мешать соседям;Референсы: у друзей картина здорово смотрится над диваном.
Пример специально упрощен, потому что как мы увидим, в жизни задачи часто формулируются в виде готового решения. В данном случае — «вбить в стену гвоздь». Это ловушка.
Подмена задачи решением
Если задача направляется исполнителю в виде решения, то все может пойти не так — во-первых, сразу отметаются альтернативные варианты, а во-вторых, без понимания настоящей задачи нельзя убедиться в работоспособности, и весь вышеупомянутый алгоритм ломается.
С 1960-х в корпоративном мире популярна карикатура с качелями на дереве. Она высмеивает то, как разные отделы интерпретируют и реализуют проектные требования. Ожидаемо, сатира прижилась и в области разработки информационных систем. Для многих это иллюстрация испорченного телефона, хотя это лишь следствие, а первопричина — за пределами изображения. Заказчик не описал свою проблему. Заказчик описал решение — качели.
Вернемся к нашему примеру с картиной. Исполнителю поручили вбить в стену гвоздь. Он не знает, для чего это, и какую ценность дает, поэтому не может предложить альтернативу — вдруг картина небольшая и легкая, и хватило бы двустороннего скотча? Вбив гвоздь, он свернет все работы и уберет инструменты, так как для него задача выполнена. Чтобы повесить картину придется во второй раз доставать стремянку, отодвигать мебель и так далее — дополнительные издержки.
Для масштабных задач эта проблема не менее актуальна. Перенесемся в сферу IT и посмотрим, как может выглядеть подмена:
«Нужно разработать кастомную ERP-систему»;«Хотим запустить мобильное приложение на iOS и Android»;«Ищем пять сениор-фронтендеров на проект»;«Сделайте SPA на React».
Неопытного исполнителя здесь ничего не насторожит. Более того, он радуется такой заявке, если она соответствует профилю услуг. А опытные знают, что это не задачи.
Здесь начинается самое интересное. Озвучив решение, клиент ждет от исполнителя предложение. В этот момент одни начнут доставать звонками и просить заполнить бриф, тогда как другие пришлют оформленные КП с приблизительной стоимостью.
Какой из подходов правильный, а какой нет, мы судить не будем. У каждого свои методы работы. Кто-то действует на авось, кто-то планирует расширять смету после старта работ, кто-то по модели fixed-price вообще не работает.
Главное, что проект подвергается рискам на самом старте — ведь может оказаться, что:
подойдет и коробочная ERP с готовыми модулями для интеграций;приложением будут пользоваться работники с Android;на проекте еще не готовы дизайн и API, фронтендеры будут простаивать;под текущий стек лучше подходит Vue.
Причина
Проблема с подменой связана с устройством контрактной работы. Как обычно происходит? Компания решает, что ей нужно что-то автоматизировать или оцифровать. Она обращается к IT-поставщикам или объявляет тендер.
Участники тендера брифуют клиента, составляют ТЗ и готовят сметы. В этих документах написано, как должно работать ПО, из каких модулей состоять, какие интеграции включать. На основании озвученных предложений по срокам и бюджетам компания выбирает подрядчика.
Исполнитель выполняет контракт. На проекте срабатывают всевозможные риски, вследствие чего страдает внутреннее качество. После сдачи исполнитель получает деньги и умывает руки, а система оказывается не приспособленной к задачам компании и дорогой в поддержке и развитии. Компания решает все переделать. Цикл повторяется.
Нарушить порочный круг можно. Далее рассмотрим как.
Истинное предназначение ТЗ
Традиция контрактной работы в том, чтобы требовать от исполнителя четкого соответствия ТЗ, соблюдения сроков и бюджетов. Уровень проработки самого ТЗ остается за рамками этой работы.
Истинная цель документа — предоставить сторонам гарантии, что исполнитель не обманет и сделает все как надо, а заказчик не потребует лишней работы и заплатит. Поэтому ТЗ прикладывают к договору.
Обратите внимание, «как надо» — это решение, а оно часто оказывается неработоспособным. В интеллектуальном труде сначала нужно понять для чего, и только потом как.
Вопросы эти должны звучать как на высоком уровне бизнес-целей, ради которых создается продукт, так и на низком, касающемся технических особенностей реализации.
И вот здесь возникают сложности. Заказчик, как правило, понимает, зачем ему нужен разрабатываемый продукт, какие потребности бизнеса он должен закрыть. Возможно есть референсы, по которым формулируются собственные пожелания. Но если речь идет о сложных системах, этого недостаточно для начала разработки.
Ситуация усугубляется путаницей вокруг ТЗ. В обиходе этот термин часто используют для описания постановки любого уровня детализации. А на самом деле это объемный документ на десятки или сотни страниц, содержащий технические подробности реализации. Но независимо от понимания, речь лишь о формате хранения самого важного — проектных требований.
Далее поговорим о содержании и качестве проработки самих требований.
Типы требований
Принято выделять четыре категории:
Бизнес-требования
Любой продукт разрабатывается для удовлетворения объективных потребностей бизнеса. Например, сотрудники предприятия работают с множеством однотипных документов, вручную внося их данные в действующую систему для последующего анализа или другого использования. Потребностью бизнеса в этом случае будет сократить время на обработку документов.
На этом этапе пока не понятно, каким именно способом должна помочь система для удовлетворения потребности. Возможны несколько вариантов решения: внедрить сервис автоматического распознавания или запрашивать данные из внешних источников и автоматически вносить в нужные реестры.
Критерии успеха также фиксируются на этом этапе. Например, «сократить средний срок обработки документов с двух дней до двух часов». Помимо конкретных целей фиксируются границы, чтобы заказчик и исполнитель понимали, когда работу над проектом можно считать завершенной.
Помочь сформировать БТ может аналитик, но полностью делегировать задачу не выйдет. Только заказчик знает все аспекты своего бизнеса и цели, для которых разрабатывается проект.
Пользовательские требования
Если бизнес-требования должны отражать потребности бизнеса, то пользовательские — потребности пользователей системы. Иными словами, пользовательские требования — это задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе (например, «регистрация на обучающий курс», «бронирование отеля» и т.д.).
Их выявлением и документированием может заниматься аналитик из команды исполнителя либо специализированная организация, согласовывая результаты работы с заказчиком.
Функциональные требования
Функциональные требования описывают то, как отвечая на конкретные воздействия пользователя будет работать каждый элемент системы. Например, «система должна отправлять на электронный адрес пользователя, сделавшего заказ, уведомления об изменении статуса заказа».
Нефункциональные требования
В отличие от ФТ описывают, как должна работать система. Они могут определяться бизнес-правилами, производительностью, аппаратной совместимостью, безопасностью, внешними интерфейсами, ограничениями дизайна и реализации. Именно здесь определяется, на каких устройствах должна работать система, какой наплыв пользователей выдерживать одновременно, и какие языки программирования и технологии использовать.
Пользовательские, функциональные и нефункциональные требования должны вытекать из бизнес-задач, соответствовать целям, ради которых создается продукт. На них нужно ориентироваться, проверяя, будет ли та или иная желаемая функция способствовать достижению целей бизнеса, и стоит ли тратить на ее описание и разработку силы.
Как описывать требования
БТ, а также нефункциональные требования удобно описывать в виде утверждений. ФТ можно описывать с помощью пользовательских историй (user stories) и сценариев использования (use cases).
Пользовательская история — это краткое утверждение о потребности пользователя, сформулированное на повседневном языке. Формируется по следующему шаблону:
Как <тип пользователя> я хочу <совершить какое-то действие>, чтобы <достичь какого-то результата>
Например: «Как посетитель сайта образовательной платформы я хочу зарегистрироваться в системе, чтобы иметь возможность записаться на интересующий меня курс».
Такая формулировка позволяет разработчикам определить типы пользователей, которым должен быть доступен данный функционал, суть самого функционала и цель его реализации.
Последнее полезно для сопоставления с БТ, чтобы можно было понять, насколько данный функционал будет соответствовать целям создания продукта. Пользовательская история не должна содержать описания конечной реализации.
Вместе с исходным утверждением формулируются критерии приемки разработанного в рамках пользовательской истории функционала. На основании этих критериев разработчики смогут выделить в рамках пользовательской истории подзадачи для реализации конкретных функций, а тестировщики — составить тесты для их проверки.
Формат удобен тем, что не требует много времени для составления, а также большого объема документации. Но с их помощью не всегда можно описать альтернативные варианты развития событий или какие-то сложные кейсы. Для таких случаев можно применять сценарии использования.
Сценарии использования — это описание последовательности взаимодействия системы и внешнего действующего лица, в результате которого действующее лицо получает полезный результат.
Структура сценариев использования может различаться на разных проектах, но, как правило, должна содержать:
название и идентификатор;наименования действующих лиц;входные и выходные условия;триггер, запускающий описываемый сценарий;пошаговое описание нормального и альтернативных направлений развития сценария;исключения;
Сценарии использования более подробны, в сравнении с пользовательскими историями, и потому более удобны для разработчиков, но в то же время на их написание уходит больше времени.
Поэтому способ описания лучше выбирать с учетом сложности, а также используемой в проекте методологии (пользовательские истории больше подходят для проектов гибкой разработки, тогда как варианты использования — в проектах с водопадной методологией).
В каком формате хранить требования
Требования к продукту фиксируются в проектной документации. Состав документации зависит от степени сложности и объемов проекта и может включать техническое задание, высокоуровневое проектирование, спецификацию на разработку, устав проекта и т.д.
Документ о концепции и границах (vision and scope document) содержит описание бизнес-контекста и концепции продукта, исходные данные, цели и задачи, критерии успеха и ограничения. Этот документ можно назвать верхнеуровневым; он нужен, чтобы зафиксировать основные ожидания от продукта.
Остальные типы фиксируются в спецификации или техническом задании, на основании которых можно приступать к написанию кода.
Спецификация требований (specifications) описывает функции и ограничения разрабатываемого продукта. Документ включает общее описание продукта, классов пользователей, которые будут с ним взаимодействовать, операционной среды, различных ограничений по дизайну и реализации, функций системы, формату данных, внешним интерфейсам и пр.
Техническое задание (statement of work) содержит подробности реализации проекта, а также описание порядка контроля и приемки системы, состава работ по вводу ее в действие, правилам документирования и источникам разработки. Однако в зависимости от проекта, какие-то разделы могут объединяться, добавляться или убираться.
Упрощая, можно сказать, что спецификация — это документ о том, как создать продукт, а ТЗ — о том, как создать и запустить. Но на практике границы размыты. Важно не название, а суть итогового документа, чтобы на его основании любая команда разработчиков смогла понять, как именно нужно реализовать желаемый продукт.
Когда аналитики слишком много или наоборот не хватает
При принятии решений могут возникать две крайности.
В первом случае — желание учесть при анализе все нюансы и найти совершенный вариант. Это приводит к так называемому аналитическому параличу (analysis paralysis), когда решение не принимается. Часто это проявляется при водопадной модели с длительными этапами планирования, сбора требований и проектирования при чрезмерно бюрократизированной корпоративной культуре.
Во втором случае — решения принимаются на лету, инстинктивно, без какого-либо систематического изучения. Вследствие чего часто оказываются поспешными и неверными, что причиняет вред организации. Это явление называют смерть от инстинкта (extinct by instinct).
Разберем это на конкретном примере. Представим, что мы хотим добавить в продукт планировщик встреч. Задача кажется простой, пока вы не изучите ее внимательно.
В первом случае подробный анализ функций ведет к бесконечно увеличивающемуся количеству функций. В случае с планировщиком может потребоваться масса элементов: выбор места, времени, участников, рассылка приглашений, интеграция календаря, вспомогательная документация и т. д. Может ли организатор менять время встречи, что если кто-то откажется присутствовать, за сколько времени уведомлять о начале? Если увлечься анализом, то с виду простая функциональность превращается в большую головную боль.
Если принимать все эти решения полагаясь исключительно на энтузиазм и интуицию, то может случиться так, что функциональность даст мало ценности для бизнеса, но ее поддержание будет отнимать ресурсы от более приоритетных задач. Стабильность бизнеса будет страдать.
Здесь нужен баланс. Аналитика должна быть достаточной, чтобы иметь под рукой всю информацию, чтобы избежать крупных неприятностей.
Далеко не всегда необходимо детальное описание абсолютно всех аспектов работы продукта до начала работы над ним. Анализа должно быть достаточно, чтобы обеспечить короткий период реализации — возможно, пилотный запуск, чтобы получить раннюю обратную связь о работоспособности решения. Затем нужен постоянный цикл диагностики и корректировки подходов.
Какой-то функционал можно отложить на последующие релизы, указав его в списке ФТ, чтобы разработчики могли сразу учесть это при проектировании системы. По задачам, которые поступают в разработку, необходимо однозначное детальное понимание результата и заказчиком и разработчиками.
Что делает клиент, а что исполнитель
Как мы уже сказали, для формализации требований требуются активное участие заказчика. Сегодня на стороне клиента может быть целый IT-отдел с собственными аналитиками и настроенным процессом постановки и декомпозиции задач. Чем больше компетенций развито внутри, тем эффективнее можно подключать для работы внешних специалистов.
Вы можете отдать на аутсорс всю разработку под ключ, включая этап аналитики, а можете обеспечить у себя процесс формализации задач и их декомпозиции и эффективно привлекать отдельных специалистов на аутстаффинг.
Например, задачи ставит менеджер, далее по ним составляется список ФТ, архитектор или старший разработчик декомпозирует их на отдельные задачи, которые можно беспрепятственно передавать внешней команде.
Обращаясь за IT-услугами, несложно попасть в ловушку контрактной работы с долгими согласованиями объемов, сроков, бюджетов, планов и графиков.
Бюрократия обещает гарантии и защиту и позволяет переложить проектные риски на сторону исполнителя, но часто от такого подхода никто не выигрывает — запуск разработки и вывод продукта на рынок задерживается, бизнес упускает прибыль и медленнее возвращает инвестиции.
При этом выявление требований — неотъемлемая часть понимания задачи. Без этого невозможно подобрать работоспособное решение. Разные типы и способы их фиксации нужны, чтобы достичь единого видения продукта заказчиком и поставщиком и выстроить эффективную стратегию аутсорсинга разработки.
