Необходимость техзадания к IT-проекту обычно сомнению не подвергается. Как правило, обе договаривающиеся стороны хорошо понимают, как важно детально обсудить и зафиксировать технические аспекты сделки, тем более, сложной и долгосрочной. Но после первых дружелюбных слов, как только дело доходит до конкретики, внезапно оказывается, что заказчик видит ТЗ одним образом, а подрядчик другим. Заказчик считает, что ТЗ должно быть бесплатным, а подрядчик закладывает его в бюджет, да еще требует авансовых платежей. Заказчик хочет «раз и навсегда», а подрядчик твердит про «итерационную разработку». Получается, что документ, который должен служить для внесения полной ясности, взаимопонимания и ускорения работы, становится роковым, из-за невозможности согласовать ТЗ срывается весь контракт.
Другая крайность, когда от ТЗ отмахиваются, подписывая вместо него какую-то формальную бумажку. Потом оказывается, что речь шла о другом функционале, сроках, интеграциях, процедурах внедрения и коммуникациях. Цены, следовательно, тоже другие, сроки сползают... Это богатая почва для конфликтов, потому что заказчик рискует приобрести ненужные ему продукты и функционал, а подрядчик рискует увязнуть в неудобном и невыгодном проекте.
В чем же проблема? Обычно в простом недопонимании. Конечно, бывают и откровенно мошеннические схемы, но это все же неприятные исключения. В интересах подрядчика сделать все добросовестно, получить благодарного постоянного клиента, регулярный доход на обслуживании и новые заказы, а также хорошие отзывы, возможно, проводить совместные маркетинговые исследования и промо-акции. Заказчик с радостью оплатит все счета, рассыплется в благодарностях и добавит подрядчиков в список VIP-персон для поздравлений по праздникам. Он всего лишь хочет получить то, за чем обратился – качественное IT-решение своих проблем. На свой, разумеется, взгляд качественное, а не по каким-то чужим непонятным метрикам, да еще за дополнительные деньги и вместо того, что было нужно с самого начала.
Давайте попробуем оценить, в чем именно и насколько сильно различается понимание разработчиками и заказчиками IT-решений подходов к техническому заданию. Свои вопросы Executive.ru адресовал обеим сторонам, участвующим в реализации проекта.
Взгляд со стороны заказчиков представляет Илья Маслихин, генеральный директор компании Starlit, занимающейся проектированием яхт, судов и судового оборудования.
Илья Маслихин, генеральный директор компании Starlit
Точку зрения разработчиков отражают ответы Егора Ермакова, архитектора решений 1C:PM в компании ITLand, специализирующейся на автоматизации управления проектами и бюджетирования в сфере среднего и крупного бизнеса.
Егор Ермаков, архитектор IT-решений компании ITLand
Executive.ru: Риторический вопрос. Нужно ли, по-вашему, ТЗ вообще?
Илья Маслихин: Да, конечно.
Егор Ермаков: Однозначно.
Executive.ru: А чья это зона ответственности? Кто должен разрабатывать ТЗ?
И.М.: Это настолько сложная и ответственная задача, что в СССР ей занимались специальные институты. Но сейчас, во-первых, насколько мне известно, уже нет таких организаций, а главное – бизнес никому не готов делегировать формулирование своих интересов. Конечно, в каждой отрасли есть много общих параметров. Но суть конкурентных преимуществ – в отличиях от рынка. Поэтому я, как заказчик, понимаю, что должен принимать активное участие в разработкеТЗ. Однако целиком брать ответственность за него довольно странно. Если я настолько хорошо разбираюсь в IT, что могу самостоятельно расставить все точки над «и», зачем тогда вообще нужен IT-подрядчик? Это он должен готовить ТЗ, а заказчик – уточнять и утверждать.
Е.Е.: Принято считать, что ТЗ – зона ответственности разработчиков. Но это справедливо только для внутреннего пользования – для тиражных продуктов, которые компания разрабатывает самостоятельно, а потом продает на них лицензии или онлайн-доступ.
В случае, когда проект делается под заказ, нужно учитывать специфику заказчика. Мы не можем угадать его бизнес-процессы, необходимо обследование. Это отдельная работа, которая должна быть выполнена с самого начала, еще до разработки ТЗ – и тем более до старта проекта. Но, насколько мне известно, далеко не все заказчики горят желанием оплачивать подготовку к подготовке к проекту. И даже если разработчик берет все расходы на себя, от клиента нужна, по крайней мере, помощь в формализации, прояснении разных вопросов. Здесь тоже не все двери настежь. «Сваливая» техзадание на разработчика, клиент сильно повышает риски проекта. Нужно делать эту часть работы совместно. Иначе получится конфликтная и опасная ситуация.
Executive.ru: Представьте, что партнер ведет себя наилучшим образом, и все двери настежь. Расскажите, что должно происходить в таком идеальном случае. К какому ТЗ нужно стремиться?
Е.Е.: Есть два основных подхода к разработке:
- Каскадный, по методологии Waterfall. Тогда сначала выясняют все требования, долго и упорно составляют детализированное ТЗ, потом строго по нему разрабатывают, тестируют и внедряют.
- Гибкий, по методологии Agile. Разработка ведется небольшими циклами, после каждого из которых актуализируются требования, критерии, планы. Фактически, на каждом этапе новое ТЗ.
Так вот, первый метод, каскадный, в целом устарел. На первый взгляд он содержит меньше рисков для заказчика, потому что все предусмотрено заранее. А на практике, поскольку сложность информационных систем значительно возросла, это попросту нереально. Невозможно все предусмотреть заранее. Более того, даже если разработчик сумеет это сделать по технической части проекта, у самого заказчика через некоторое время поменяются бизнес-процессы, часть функционала понизится по приоритету, возникнут новые запросы. И если подрядчик поведет себя формально – будет постоянно цитировать согласованное техзадание, а дальше трава не расти – очевидно, что ни к чему хорошему это не приведет.
Большинство современных команд разработки стараются убедить заказчиков перейти на гибкую методологию. Это позволяет обрабатывать все уточнения и новые требования без малейшего ущерба для проекта. В конечном счете, Agile, конечно, значительно эффективнее и экономичнее. Но здесь необходим высокий уровень доверия.
Executive.ru: Илья, вы готовы доверить подрядчику разработку по Agile?
И.М.: Давайте уточним, что именно под этим подразумевается. Готов ли я регулярно обновлять требования и проверять, верным ли курсом движется разработка? Безусловно. Конечно, полезно определить общее направление, задать вектор, а потом пошагово его детализировать. Но если под регулярным пересмотром понимается неограниченное раздувание сроков и постоянный рост расходов – какого заказчика это обрадует? Меня точно нет. Тем более что мы разрабатываем проектную документацию в рамках сложных комплексных проектов. Например, один из наших крупнейших заказчиков – Военно-морской флот РФ. Там жесткие сроки, бюджеты согласуются далеко наверху, и раз в пару недель заявлять, что «все поменялось» – даже не смешно. Такие варианты не рассматриваются вообще.
Некие определенные рамки, так или иначе, должны быть известны с самого начала. Можно учесть маржу на доработки, это нормально. Можно менять по ходу мелкие детали, очередность задач, еще чего-то. Но нельзя допускать раздувания сроков и бюджета.
Executive.ru: Егор, по Agile можно работать в рамках жесткого бюджета и соблюдая четкий план-график?
Е.Е.: В принципе да. Только, если пошел такой разговор, тоже хочу сделать уточнение. Кто именно возьмет на себя ответственность за эти жесткие рамки, на каком основании? Если речь идет о техническом обеспечении проекта в идеальных статических условиях, то есть о программном обеспечении, пусть даже в некоторых случаях о программно-аппаратных системных решениях – разработчик может оценить все с большой точностью, действительно учесть маржу про запас, и выполнить обязательства день в день, рубль в рубль. Или даже быстрее и дешевле.
Но если подразумевается не только техническая часть, а проект в целом – часто именно об этом идет речь, и это основная причина для использования гибких методов разработки – тогда все гораздо сложнее. Потому что разработкой дело не ограничивается, это всего лишь часть проекта. В уравнении много других переменных. Нужно:
- Выявить реальные потребности заказчика.
- Синхронизировать это понимание с уже имеющимся программным обеспечением, чтобы выполнить интеграцию.
- Позаботиться о переносе данных.
- Обучить сотрудников заказчика.
- Предусмотреть, как принятые решения скажутся на работе предприятия во время и после внедрения.
- Зарезервировать время ключевых сотрудников заказчика на регулярные уточнения требований, причем не по факту возникновения проблем, а в любом случае (это особенно важно, и с этим часто бывают проблемы).
Заказчик сам должен хорошо подумать, а потом вместе с нашими аналитиками обсудить, какие именно результаты ему нужны и зачем. Он должен установить приоритеты и обозначить, в каких диапазонах, по каким причинам они могут меняться. При таком подходе можно рассчитывать на успех. Еще раз подчеркну: разработчик не может нести ответственности за непонимание заказчиком сути своих задач. А когда заказчик говорит, что готов сходу назвать все свои ключевые требования, это практически всегда означает: жди беды. Потому что сроки и бюджеты должны быть результатом анализа, а не декларироваться.
Executive.ru: Илья, вам есть что добавить к этому?
И.М.: Анализ требований, время на обсуждение корректировок, выяснение взаимосвязей – все это звучит довольно логично. Главное, чтобы подрядчик не пытался спрятаться за красивыми словами от простой и принципиальной вещи: он в проекте для того, чтобы помогать найти решение и добиваться результата, а не чтобы обосновать какими-то научными методологиями объективную невозможность решения в первоначальных рамках.
Ведь как часто происходит – на первых встречах о рисках внедрений IT-продуктов почти не упоминается. Это такая безделица, что не стоит даже упоминать. А потом, когда проект уже стартовал, на него выделены ресурсы и частично даже потрачены, вдруг (!) выясняется, что потребуются дополнительные работы, задача недостаточно четко сформулирована и т.д. Зачем же вы брались за эту мутную задачу, позвольте спросить? Почему не уточнили все до начала проекта, не предупредили о том, что бюджет нереален?
Executive.ru: Егор, зачем вы брались, почему не предупредили заранее? Если, конечно, такие случаи были в вашей практике.
Е.Е.: Формально я мог бы спрятаться за коллег, потому что разработчики не обсуждают условий с заказчиками, для этого есть продавцы, менеджеры и руководители проектов. Но здесь вопрос довольно простой. Я больше трех лет руководил отделом разработки и хорошо понимаю, как оцениваются задачи в часах. Если известны задачи, они четко сформулированы – значит, будет не менее четкая оценка трудоемкости их выполнения. Естественно, с учетом подводных камней и различных рисков, о которых хороший РП знает заранее, и может сразу их учесть. Здесь проблем не возникает.
Узкое место, извините, на территории заказчика. Это не значит, что я, как разработчик, пытаюсь свалить с себя ответственность, ничего подобного. Но и брать чужую ответственность тоже не могу. Речь ведь не об игре «поиск виноватого». Мы говорим о том, как добиться результата, нужного заказчику – причем в устраивающих его ограничениях. И часто, помимо объективных ограничений, заказчики создают также субъективные, совершенно лишние.
Простой и часто встречающийся пример. Практически любой проект предусматривает разработку форм для ввода данных и составления отчетов. Можно подойти к постановке задачи функционально, предоставив разработчикам самостоятельно искать оптимальные пути реализации. А можно очень жестко потребовать создать формы определенного вида, подробно прописав, где расположены разные кнопки, как они взаимодействуют и т.д. Заказчик уверен, что это то самое идеальное техзадание: все прописано, остается всего лишь сделать. Но зачастую в силу ограничений платформы и по другим причинам можно за счет очень незначительных модификаций ощутимо выиграть в скорости. Соответственно, это будет и дешевле. И вот мы спрашиваем заказчика: давайте так сделаем, немного другая форма, зато лучше. Если он говорит: «У нас есть ТЗ, мы потратили на него время, вот так и делайте». Разработчики соглашаются: да, конечно. Один раз так, второй, третий. Потом они перестают предлагать улучшения: проще без разговоров следовать ТЗ. И это всего лишь отчет или форма. Теперь перенесите эту проблему на более сложные и важные задачи. Например, какой-то бизнес-процесс обсудили и прописали в ТЗ. Потом, в ходе реализации, выясняется, что этого недостаточно. Или есть конфликт с другими процессами.
Часто бывает, что заказчик неожиданно вспоминает о чем-то важном. И у нас возникает тот же самый вопрос: что же вы раньше молчали? Всегда есть опасность, что небольшие уточнения сильно поменяют картину в целом. Нельзя достроить здание до половины, а потом сказать: «Кстати, давайте увеличим число этажей в два раза. За кирпичи и работу доплатим». Фундамент не выдержит, потребуется другая конструкция, возможно даже укрепление почвы. Это не просто дороже, это вообще другой проект. Даже с нуля начать всю работу может оказаться проще и дешевле, чем добавлять некоторые «заодно».
Executive.ru: Итак, качество ТЗ зависит от взаимопонимания между заказчиком и разработчиком IT-решения. Это логично. А есть какие-то приемы, методы для сближения позиций? Что конкретно вы можете посоветовать друг другу?
Е.Е.: Пожалуй, вот самые важные рекомендации:
- Не жалейте времени на уточнение терминологии. Большинство проблем можно решить или не дать им возникнуть, если просто назвать вещи своими именами, и понять друг друга в прямом, буквальном смысле.
- Заказчик должен понимать, что разработка программного обеспечения – такая же материальная технология, как строительство или сборка автомобиля. Если что-то забыли учесть заранее, придется это переделать, и, разумеется, переделки изменят параметры проекта. Хотите обойтись без неожиданностей – учитывайте их в планах заранее. Начиная с обследований, и потом в виде корректировок, доработок.
- Гибкая разработка дает ряд преимуществ, но чтобы ими воспользоваться, нужны взаимные усилия. Собственно, это вообще ключевой момент: разработка информационной системы – не покупка. Можно купить тиражное решение по фиксированной цене. А разработка и внедрение по индивидуальному заказу критично зависят от нюансов, справиться с которыми можно только вместе, действуя как партнеры.
И.М.: Частично повторюсь, но думаю это важно: Уважаемые разработчики:
- Начинайте свои презентации с оценки полной стоимости IT-решений. Не для протокола, а как раз для взаимопонимания. Все те уточнения и дополнительные аспекты, о которых вы уже знаете как лидер отрасли с многолетним опытом – озвучивайте сразу, пожалуйста.
- Не стесняйтесь переспрашивать заказчиков, чтобы получить всю нужную вам информацию. Предупреждайте о рисках. Громко, отчетливо говорите, в каких случаях не просто возможны некоторые затруднения, а вообще ничего не получится.
- И самое главное – отказывайтесь от тех проектов, которые считаете невыполнимыми. Просто не беритесь за них. Тогда заказчик будет искать другого IT-партнера, который справится, либо получит веский повод для радикального пересмотра условий.
Фото: pixabay.com, архивы спикеров
Валерий, я как раз и говорю о том, что коробочка лежит в голове бизнес-аналитика разработчика. А заказчику лень изучать свой бизнес, то есть понять то чем занимаются его операционные, линейные менеджеры. Ему времени едва хватает, что бы разгребать текучку.
Вот эта излюбленная формула - "решают в тесном контакте", на самом деле фейк. Нет там никакого тесного контакта, если нет модели. Если модель есть и люди умеют работать с ней, то местный аналитик всегда сможет выгрузить вам любую форму. У меня это ТЗ и бизнес-требования.
Не верю в то. что у руководителей любого действующего предприятия нет хотя бы в голове модели этого бизнеса.Тогда бы он не существовал.Но вот форматы его представления могут не совпадать с форматами представителей Ит-отрасли.И согласование этих форматов и представлений концентрируется в техническом задании.В статье об этом писалось и я сам использую на практике предварительное обследование действующего бизнеса.У себя я это называю "технологический паспорт" Он уже содержит простейшие рекомендации по развитию предприятия.В нашем случаи это может быть Ит-аудит или другая форма.После такой работы разговаривать с заказчиком намного легче. В одном из комментариев звучало: заказчик часто не до конца понимает возможности предлагаемых решений. Самое интересное, что он часто именно из-за этого нанимает посторонние организации и готов за это платить деньги.Если ему все ясно, то справятся мои специалисты.
На каком то достаточно высоком уровне конечно есть. Но проблемы то не с концепцией бизнеса, а с низким уровнем - операциями. Причем с согласованным действием всех процессов низкого уровня.
У меня был случай, когда я формируя модель никак не мог добиться "тесного контакта" с начальником отдела продаж. В его open space сидело 60 человек. Наконец он признался, что не может быть экспертом и никто другой не может быть экспертом по причине, что никто не знает чем занимается (какие операции выполняет) его сосед. Все 60 человек выполняли разные исторически сложившиеся операции. Единой модели управления людьми, ресурсами, документами не было - не сложилось.
Михаил, если бизнес работает, то реально эта модель есть.Она может быть не достаточно формализованной в бумажном виде, хотя даже принятие на должность- это уже элемент модели.Предприятие отчитывалось по налогам- это модель движения документов.
Еще можно говорить об эффективности модели.Я, конечно, могу ошибаться. но Ит-решения редко применяют как вариант инструмент решения управления к кризисной ситуации.Они могут быть только инструментом для коренных преобразований.
Да Николай, эту формулу я слышу постоянно. Деятельность какая то ведется. Но единой модели нет - у всех она разная в головах. Если это кого то устраивает, то зачем вообще приглашать айтишников что то автоматизировать - лишать людей свободы творчества )))
Неплохо было бы для начала дать четкое определение что такое "ТЗ" (назначение, содержание, стандарты и т.д.), а уже потом обсуждать кто, когда и зачем его должен готовить.
Если по простому, то начальный вариант ТЗ - это выраженное в простой письменной форме: "Мне надо чтобы было вот так и вот так". По мере получения от заказчика ответов на вопрос "а если то-то?," "а как быть если так-то?", формируется что-то более-менее конкретное.