Что не так с постановкой задач IT-исполнителям при контрактной работе и как не попасть в ловушку

Представим, что нужно узнать стоимость и сроки разработки, но исполнитель не торопится озвучивать предложение, дает большие «вилки», а для точности просит ТЗ, хотя ему уже все предоставили. Разбираемся, почему так происходит и что с этим делать.

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

Этот алгоритм подходит для любой ситуации, даже самой мелкой бытовой:

Пример специально упрощен, потому что как мы увидим, в жизни задачи часто формулируются в виде готового решения. В данном случае — «вбить в стену гвоздь». Это ловушка.

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

С 1960-х в корпоративном мире популярна карикатура с качелями на дереве. Она высмеивает то, как разные отделы интерпретируют и реализуют проектные требования. Ожидаемо, сатира прижилась и в области разработки информационных систем. Для многих это иллюстрация испорченного телефона, хотя это лишь следствие, а первопричина — за пределами изображения. Заказчик не описал свою проблему. Заказчик описал решение — качели.

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

Для масштабных задач эта проблема не менее актуальна. Перенесемся в сферу IT и посмотрим, как может выглядеть подмена:

Неопытного исполнителя здесь ничего не насторожит. Более того, он радуется такой заявке, если она соответствует профилю услуг. А опытные знают, что это не задачи.

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

Какой из подходов правильный, а какой нет, мы судить не будем. У каждого свои методы работы. Кто-то действует на авось, кто-то планирует расширять смету после старта работ, кто-то по модели fixed-price вообще не работает.

Главное, что проект подвергается рискам на самом старте — ведь может оказаться, что:

Проблема с подменой связана с устройством контрактной работы. Как обычно происходит? Компания решает, что ей нужно что-то автоматизировать или оцифровать. Она обращается к IT-поставщикам или объявляет тендер.

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

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

Нарушить порочный круг можно. Далее рассмотрим как.

Традиция контрактной работы в том, чтобы требовать от исполнителя четкого соответствия ТЗ, соблюдения сроков и бюджетов. Уровень проработки самого ТЗ остается за рамками этой работы.

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

Обратите внимание, «как надо» — это решение, а оно часто оказывается неработоспособным. В интеллектуальном труде сначала нужно понять для чего, и только потом как.

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

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

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

Далее поговорим о содержании и качестве проработки самих требований.

Все проектные требования принято делить на четыре категории:

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

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

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

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

Если бизнес-требования должны отражать потребности бизнеса, то пользовательские требования — потребности пользователей системы. Иными словами, пользовательские требования — это задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе (например, «регистрация на обучающий курс», «бронирование отеля» и т.д.).

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

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

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

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

Бизнес-требования, а также нефункциональные требования удобно описывать в виде утверждений. Пользовательские и функциональные требования можно описывать с помощью пользовательских историй (user stories) и сценариев использования (use cases).

Пользовательская история — это краткое утверждение о потребности пользователя, сформулированное на повседневном языке. Формируется по следующему шаблону:

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

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

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

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

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

Структура сценариев использования может различаться на разных проектах, но, как правило, должна содержать:

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

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

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

Документ о концепции и границах (vision and scope document) содержит описание бизнес-контекста и концепции продукта, исходные данные, цели и задачи, критерии успеха и ограничения. Этот документ можно назвать верхнеуровневым; он нужен, чтобы зафиксировать основные ожидания от продукта.

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

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

Техническое задание (statement of work) содержит подробности реализации проекта, а также описание порядка контроля и приемки системы, состава работ по вводу ее в действие, требования к документированию и источники разработки. Однако в зависимости от проекта, какие-то разделы могут объединяться, добавляться или убираться.

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

При принятии решений могут возникать две крайности.

В первом случае — желание учесть при анализе все нюансы и найти совершенный вариант. Это приводит к так называемому аналитическому параличу (analysis paralysis), когда решение не принимается. Часто это проявляется при водопадной модели с длительными этапами планирования, сбора требований и проектирования при чрезмерно бюрократизированной корпоративной культуре.

Во втором случае — решения принимаются на лету, инстинктивно, без какого-либо систематического изучения. Вследствие чего часто оказываются поспешными и неверными, что причиняет вред организации. Это явление называют смерть от инстинкта (extinct by instinct).

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

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

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

Здесь нужен баланс. Аналитика должна быть достаточной, чтобы иметь под рукой всю информацию, чтобы избежать крупных неприятностей.

Далеко не всегда требуется детальное описание абсолютно всех аспектов работы продукта до начала работы над ним. Анализа должно быть достаточно, чтобы обеспечить короткий период реализации — возможно, пилотный запуск, чтобы получить раннюю обратную связь о работоспособности решения. Затем нужен постоянный цикл диагностики и корректировки подходов.

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

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

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

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

Обращаясь за IT-услугами, несложно попасть в ловушку контрактной работы с долгими согласованиями объемов, сроков, бюджетов, планов и графиков.

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

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