Заказчик хочет поручить сторонней организации (например, консультанту) решение некоторой проблемы (выполнение некоторой работы). Кто должен определить необходимый объем работ и перечень задач? Заказчик или исполнитель? Или может быть они должны совместно участвовать в формулировании «технического задания»?
Рассмотрим ситуацию, когда заказчику нужно решить некоторую проблему, однако он не может достаточно четко ее сформулировать (во взаимосвязи со своими долгосрочными целями, другими проблемами и тому подобном).
Типичным для такого случая поведением внешнего консультанта будет «помощь» заказчику при формулировании техзадания, при этом консультант, вполне вероятно, может проектировать техзадание с «уклоном» в свою сторону, с учетом, так сказать, своих интересов, однако это лучше, чем просто сделать, как скажет заказчик. Действительно, попытка в такой ситуации буквально выполнить то, что просит клиент, в большинстве случаев не сделает никого счастливым.
Теперь давайте посмотрим другой вариант. Задача настолько банальна для клиента, что он в состоянии сформулировать ее достаточно хорошо. С одной стороны, это хорошо для внешних исполнителей — ведь всем все понятно, но здесь сложность может быть в том, что с точки зрения заказчика, если он хорошо понимает задачу и способ ее решения, значит и стоимость работы не должна включать поиск решения, а, следовательно, такая работа оплачивается гораздо ниже, чем в предыдущем случае.
В такой ситуации может возникать поведение исполнителя, направленное на искусственное усложнение ситуации с целью повысить профессиональную значимость и/или гонорар, что может приводить к нежелательным последствиям для клиента.
Конечно, для большинства внешних консультантов идеальной была бы ситуация, когда клиент полностью доверяет мнению консультанта, утверждает и оплачивает то, что предлагает консультант, не требуя при этом неопровержимых доказательств работоспособности предложений.
И, пожалуй, такой подход имеет право на существование именно в том случае, когда клиент не знает решения проблемы, а консультант знает решения надлежащего качества. Но тогда без проблем можно гарантировать качество решения и получать гонорар в привязке к результату.
Однако можно выделить такую группу ситуаций, когда решаемая проблема на текущем этапе не имеет приемлемого решения, таким образом, нет возможности использовать кем-то отработанные стандарты и решение проблемы превращается в исследовательский процесс с неопределенным исходом.
Анализ ряда таких «проектов» показывает, что корреляция успешного исхода и компетенции привлеченных специалистов невелика, по-видимому, гораздо важнее здесь другое условие — над проблемой должны работать только внутренние специалисты организации, так как без этого невозможно добиться исключительной концентрации на решении проблемы (это невозможно для стороннего консультанта, имеющего и ответственность перед своей фирмой и профессией). Кроме того, без этого невозможно обеспечить полную интеграцию нового уникального решения в пределах всей организации.
Подтверждение этому можно найти в любой отрасли — на ранних этапах любого продукта все работы по совершенствованию, как правило, сосредоточены внутри компании-производителя, и, только когда продукт становится достаточно «качественным» для запросов рынка, появляется возможность стандартизовать отдельные компоненты и требования к совместимости и выделить производство таких компонентов во внешнюю среду.
На таком «зрелом» этапе мы можем увидеть другую картину — попытки оставить весь цикл разработок и производства в рамках одной компании уже не дают эффект (требуемый уровень качества уже достигнут), а затраты на поддержание такой интегрированной системы огромны и не окупаются. Как следствие, такая компания обречена проиграть в себестоимости и уступает долю рынка более стандартым продуктам (например, Apple в 90-е).
Чтобы обобщить эти размышления, предлагаю выделить пять вариантов работы «над проблемой клиента», в зависимости от существования решения этой проблемы и от того, кому оно известно.
Таблица 1. Варианты работы над техническим заданием
|
Существует надежное решение
|
Известно консуль-танту
|
Решение известно Клиенту
|
Форма работы консультанта над проблемой
|
Составитель техзадания (ТЗ) и форма постановки задачи
|
|
−
|
−
|
−
|
внутри организации, участие в поиске решения
|
общая формулировка проблемы уточняется в ходе работы над ней
|
|
+
|
−
|
−
|
участие в проекте выбора и внедрения
|
формулировка задачи подразумевает диапазон решений
|
|
+
|
+
|
−
|
участие в рабочей группе в качестве эксперта
|
ТЗ составляется консультантом,
утверждается Клиентом
|
|
+
|
−
|
+
|
участие в рабочей группе в качестве модератора
|
Клиент сам для себя определяет техническое задание
|
|
+
|
+
|
+
|
выполнение стандартной работы
|
исчерпывающее ТЗ
составляется Клиентом
|
В первом случае крайне важно, чтобы консультант был полностью интегрирован внутрь организации, включая все необходимые полномочия и ответственность, при этом он должен «сложить» все свои оставльные (внешние) полномочия и ответственность, что резко повысит вероятность нахождения и внедрения оптимального для организации решения.
Во втором случае интеграция консультанта необязательна, хотя и желательна, при этом нужно отметь, что и в первом и во втором случаях не видно явной причины для привлечения консультанта, такой причиной может стать предполагаемый высокий опыт «около» данной проблемы, близость консультанта к внутренней «кухне» организации и многое другое, нужно или нет здесь привлекать и кого привлекать — достойные отдельной статьи вопросы.
В третьем случае консультант выступает в роли эксперта и на нем ответственность за разработку и аргументацию технического задания. Повторюсь, что в этом случае консультант может гарантировать результат от своей работы, иначе это первый или второй случай.
В четвертом случае внешний консультант может помочь заказчику «увидеть» известное, но по каким-то причинам еще невидимое решение. То есть катализировать, фасилитировать и прочее. Часто для обозначения этого типа консультирования используют термин «процессный консалтинг», однако, на мой взгляд, этот термин не очень красив, так как пересекается по смыслу и консультированием по оптимизации бизнес-процессов.
В этом четвертом случае нужно изменить задачу для консультанта, чтобы она перешла к третьему или пятому случаю. Как это сделать? Поставить задачу именно в том виде, в каком консультант специалист — ускорение процесса принятия решений.
В пятом случае заказчик поручает исполнителю стандартизованную работу, у которой известен не только результат, но и четко определен процесс выполнения. В этом случае техническое задание может и должен сделать заказчик, чтобы исключить ненужное творчество и чтобы выйти за рамки существующих технологий, стандартов и решений, которые уже наработаны в компании заказчика в этой области.
Фото: pixabay.com
Тяжелое впечатление от статьи.
Хотелось бы понять, для какой аудитории она писана? По логике она писалась для потенциальных заказчиков. Тогда её должен был бы писать какой-нибудь консультант. Но статья не оставила чувства того, что она написана консультантом. Она мне показалась слишком путаной, в изложении плохо просматривается логика. Опять же автор так оперирует понятиями ''консультант'' и ''исполнитель'', что не поймешь: это одно или разные лица. Я так понимаю, по предыдущим высказываниям, что такое чувство сформировалось не только у меня.
Еще один вопрос. Когда автор использует понятие ''Техзадание'', то что он имеет в виду? Я видел в жизни разные документы, которые их составители пытались выдать за ТЗ. В них область проблем (''ЧТО система должна делать и/или ДЛЯ ЧЕГО использоваться'') смешивалась с областью решений (КАК и/или ЗА СЧЕТ чего система будет что-то делать и/или как-то использоваться). Поэтому правильнее было начать с четкой формулировки понятия дабы люди несведующие четко понимали смысл понятий. Кстати, у меня от статьи сложилось впечатление, что и автор смешивает в понимании ТЗ области проблем и решений.
Лично я так бы ответил на поставленный статьей вопрос:''Кто пишет техзадание?'': т.к. техзадание представляет набор требований из области проблем, то писать его должен заказчик (если у него есть квалифицированные специалисты) или консультант (заказчик, естественно, утверждает ТЗ). Хотелось бы подчеркнуть, что роль консультанта при формировании техзадания заключается в том, чтобы в этом документе максимально точно были отражены проблемы, ключевые требования и ограничения проекта. Консультант на этом этапе выбирается не среди экспертов предметной области, а среди специалистов, умеющих извлекать потребности и знания из подсознания ''заказчика''.
А вот консультант-эксперт в предметной области заказчику понадобиться, когда придет черед описывать видение решения задачи и разрабатывать или оценивать техпроект.
Что касается написания техзадания исполнителем, да, на практике такое нередко встречается. В этом случае заказчик должен четко осознавать, что задание исполнителем будем максимально подогнано под себя, и учитывать это в оценке рисков проекта.
Примечание: сомневающимся в моей трактовке техзадания предлагаю ознакомиться, например, с работами Г. Буча, Э. Халл, К. Джексона, К.Вигерса