Необходимость техзадания к 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, архивы спикеров
Хочется задать вопрос. Как оценивать пожелания заказчика типа "Я хочу как у ... (Газпрома, например)". С одной стороны - да, действительно, решение есть, и оно работает, и, в принципе, его можно повторить. Но, с другой стороны, решение нестандартное, разрабатывалось специально для конкретного заказчика, и сколько уйдет на него времени даже приблизительно предсказать сложно.
Как вы поступаете в таком случае, Егор?
Для меня тема очень близка и актуальна.Пусть я не работаю в сфере ИТ, но разработка технологических паспортов и технологических проектов крупных молочно-товарных комплексов без формирования четкого технического задания просто не возможна.Со второй частью проще- новые проекты привязываешь к местным условиям и дело касается больше пожеланий потребителя.
Но вот модернизация действующего производства- это уже ближе к теме.Здесь по неволе приходиться работать по Agile .Не было ни одного проекта, что бы не пришлось предлагать заказчику менее 3-4 концептуальных вариантов таких решений.Самый близкий пример- разработка проекта молочно-товарной фермы по производству молока для твердых сыров.Заказчик-Олег Сирота.Только на первом этапе было три варианта коровников, сейчас уже пятый.Но это нормально.Современные информационные продукты позволяют создать коныептуальный вариант длостаточно бысторо, и не требует использования больших ресурсов.
Николай, во сфере ИТ нет особой специфики относительно общего подхода... Разработка ТЗ Проекта это функция и ответственность заказчика Проекта... Заказчик может поручить разработку любой другой организации, в т.ч. и исполнителю этого ТЗ в последующем... И в этом случае должно быть уже свое ТЗ на разработку ТЗ Проекта и т.д. И естественно такая работа должна быть оплачена...
А это такие частности при чем не технического характера
А вот здесь вы полностью неправы.Описываемые в статье случаи- это чистой воды модернизация.Необходимо ввести Ит-решения в действующую систему бизнеса, и эти решения должны быть эффективными, то есть принести больший доход, чем были затрачены ресурсы.Просто мой профиль шире- кроме Ит-решений, например, системы учета в организации кормления в режиме реального времени. есть чисто производственные моменты, связанные с животными, получением конечного продукта и так далее.
Абсолютно согласен с этим утверждением! Все дальнейшие проблемы, как раз от того что "Заказчик считает, что ТЗ должно быть бесплатным". То есть мыслей о том, что сам заказчик должен поставить задачу даже не возникает. Думают только, а будет ли эта работа поставщика оплачена или нет.
Хотя в большинстве случаев она будет оплачена, пусть и в неявной форме.
Понятно, что причина неспособности заказчика, чаще из-за отсутствия профессионалов, сформулировать задачи проекта (и речь идет не только о технической формулировке, а даже в виде алгоритмов или бизнес-моделей) заказчик не умеет. Особенно это касается информационных систем, но в принципе относится ко всему, что не является основным видом деятельности заказчика.
И исполнителю ничего не остается, как собирать по крупицам "пожелания", часто с помощью показов - "можно так", "а можно и так", "есть такой функционал", когда клиент тыкает пальцем в картинку (порой - что бы отцепились). Результат - непредсказуем.
Хороший (опытный) исполнитель либо страхуется подписанием "бумажек", либо действительно тратит свои ресурсы на обучение сотрудников заказчика, что бы они могли осознанно сделать выбор.
Как мне кажется, один из удобных вариантов иметь готовый базовый проект, с достаточной детализацией и желательно уже реализованный, который допиливать по обстановке.
А я категорически НЕ СОГЛАСЕН!!
Я, как руководитель компании по разработке ПО для банков, утверждаю что для сложных продуктов ТЗ не может быть разработано заказчиком.
Исключением может является ситуация автоматизации хаоса. Это когда заказчик хочет "чтоб было как раньше" но на компах. Именно только в таком случае исполнитель хочет/ждет получить от заказчика "а как же было до того..."
В нашем бизнесе, где покупка ПО в основном связана с внедрением в банке новых технологий, сотрудники банка ОЧНЬ слабо себе представляют возможности системы, и тем самым НЕ МОГУТ написать ТЗ.
Кроме того я в статье не заметил (может не внимательно читал) что же автор понимает по ТЗ. Технические Задания могут быть достаточно разные по структуре и содержанию. Я часто в литературе видел путаницу в определении что такое "Требования" и что такое "Техничесоке задание".
Мы в своей практике совместно с банком пишем (мы), согласовываем и обязательно подписываем документ "Требования к системе". В этом документе на языке бизнеса описываем "хотелки" сотрудников банка. Почему мы? Потому что нужно информацию систематизировать, брать противоречия и привести к ощему пониманию терминов.
Только после утверждения "Требований с системе" уже мы разрабатываем ТЗ. Если коротко то в нем указано что и как мы будем делать и какой конкретоно результат они получат. Естественно сначала драфт ТЗ обсуждаются, согласовывается, корректируется и только при полном согласии УТВЕРЖДАЕТСЯ!
Я как раз тот кто считает наоборот. Объясню. Это мое видение...
Как правило заказчик (как это ни странно) плохо знает свой бизнес - именно на операционном уровне. Что бы его хорошо знать, нужно перейти от ручного фрагментарного управления к системному. Создать модель бизнеса (напоминаю, мы говорим о крупном заказчике). Ему нужно уметь управлять своим бизнесом через эту модель, то есть непрестанно трудиться над тем что бы внедрять в практику то, что создано в модели. Лишь тогда у заказчика появится целостное представление о том, что требуется для повышения производительности своего бизнеса.
Но обычно, если и есть модель, то о них знают очень ограниченное число специалистов и вряд ли она отражает , то что в действительности должно происходить. Заказчик не понимает ценности моделирования.
Когда приходит разработчик, то он вперед запускает своих бизнес-аналитиков, у которых особенно то и нет времени рассусоливать с заказчиком. Их основная задача - подогнать ТЗ под имеющееся решение. Не самый плохой вариант, но и не самый хороший для (напоминаю опять) крупного заказчика. Так как вместе с водой можно выплеснуть и все конкурентные отличия, skills .
Мой вывод - ТЗ должен писать заказчик, это его обязанность. Но писать он его должен обязательно на основании модели. Ее отсутствие в практике управления и создает все те колизии, которые описаны в статье.
Соглашусь, что такое может быть. Зависит от системы и когда есть типовые решения.
У нас, не коробочный продукт, а конструктор. После установки система не умеет делать НИЧЕГО. Для того, чтоб она заработала нужно ввести в нее бизнес-процесс и настроить его под особенности оргструктуры клиента. Наши бизнес-аналитики как раз и решают задачу формирования модели в тесном контакте с заказчиком.
Валерий,
То, что для сложных продуктов ТЗ не может быть разработано заказчиком не противоречит тому , что ТЗ должен разрабатывать заказчик, т.к. это его функция и его ответственность, при чем документированная в виде грифа утверждения ТЗ. А кто разрабатывает ТЗ, он сам, или его подрядчик, определяется им самим в т.ч. с учетом имеющихся у него компетенций...
Модернизация или нововведение в контексте заявленной проблемы не имеет ни какого значения... ТЗ проекта на нововведение или модернизацию, это функция заказчика проекта. Требования к подрядчику о конкретной модели организации работ по проекту типа Agile, Prince2 т.п. можно отнести к Design Specification (Техническое задание) с определенной условностью...