Заказчик хочет поручить сторонней организации (например, консультанту) решение некоторой проблемы (выполнение некоторой работы). Кто должен определить необходимый объем работ и перечень задач? Заказчик или исполнитель? Или может быть они должны совместно участвовать в формулировании «технического задания»?
Рассмотрим ситуацию, когда заказчику нужно решить некоторую проблему, однако он не может достаточно четко ее сформулировать (во взаимосвязи со своими долгосрочными целями, другими проблемами и тому подобном).
Типичным для такого случая поведением внешнего консультанта будет «помощь» заказчику при формулировании техзадания, при этом консультант, вполне вероятно, может проектировать техзадание с «уклоном» в свою сторону, с учетом, так сказать, своих интересов, однако это лучше, чем просто сделать, как скажет заказчик. Действительно, попытка в такой ситуации буквально выполнить то, что просит клиент, в большинстве случаев не сделает никого счастливым.
Теперь давайте посмотрим другой вариант. Задача настолько банальна для клиента, что он в состоянии сформулировать ее достаточно хорошо. С одной стороны, это хорошо для внешних исполнителей — ведь всем все понятно, но здесь сложность может быть в том, что с точки зрения заказчика, если он хорошо понимает задачу и способ ее решения, значит и стоимость работы не должна включать поиск решения, а, следовательно, такая работа оплачивается гораздо ниже, чем в предыдущем случае.
В такой ситуации может возникать поведение исполнителя, направленное на искусственное усложнение ситуации с целью повысить профессиональную значимость и/или гонорар, что может приводить к нежелательным последствиям для клиента.
Конечно, для большинства внешних консультантов идеальной была бы ситуация, когда клиент полностью доверяет мнению консультанта, утверждает и оплачивает то, что предлагает консультант, не требуя при этом неопровержимых доказательств работоспособности предложений.
И, пожалуй, такой подход имеет право на существование именно в том случае, когда клиент не знает решения проблемы, а консультант знает решения надлежащего качества. Но тогда без проблем можно гарантировать качество решения и получать гонорар в привязке к результату.
Однако можно выделить такую группу ситуаций, когда решаемая проблема на текущем этапе не имеет приемлемого решения, таким образом, нет возможности использовать кем-то отработанные стандарты и решение проблемы превращается в исследовательский процесс с неопределенным исходом.
Анализ ряда таких «проектов» показывает, что корреляция успешного исхода и компетенции привлеченных специалистов невелика, по-видимому, гораздо важнее здесь другое условие — над проблемой должны работать только внутренние специалисты организации, так как без этого невозможно добиться исключительной концентрации на решении проблемы (это невозможно для стороннего консультанта, имеющего и ответственность перед своей фирмой и профессией). Кроме того, без этого невозможно обеспечить полную интеграцию нового уникального решения в пределах всей организации.
Подтверждение этому можно найти в любой отрасли — на ранних этапах любого продукта все работы по совершенствованию, как правило, сосредоточены внутри компании-производителя, и, только когда продукт становится достаточно «качественным» для запросов рынка, появляется возможность стандартизовать отдельные компоненты и требования к совместимости и выделить производство таких компонентов во внешнюю среду.
На таком «зрелом» этапе мы можем увидеть другую картину — попытки оставить весь цикл разработок и производства в рамках одной компании уже не дают эффект (требуемый уровень качества уже достигнут), а затраты на поддержание такой интегрированной системы огромны и не окупаются. Как следствие, такая компания обречена проиграть в себестоимости и уступает долю рынка более стандартым продуктам (например, Apple в 90-е).
Чтобы обобщить эти размышления, предлагаю выделить пять вариантов работы «над проблемой клиента», в зависимости от существования решения этой проблемы и от того, кому оно известно.
Таблица 1. Варианты работы над техническим заданием
|
Существует надежное решение
|
Известно консуль-танту
|
Решение известно Клиенту
|
Форма работы консультанта над проблемой
|
Составитель техзадания (ТЗ) и форма постановки задачи
|
|
−
|
−
|
−
|
внутри организации, участие в поиске решения
|
общая формулировка проблемы уточняется в ходе работы над ней
|
|
+
|
−
|
−
|
участие в проекте выбора и внедрения
|
формулировка задачи подразумевает диапазон решений
|
|
+
|
+
|
−
|
участие в рабочей группе в качестве эксперта
|
ТЗ составляется консультантом,
утверждается Клиентом
|
|
+
|
−
|
+
|
участие в рабочей группе в качестве модератора
|
Клиент сам для себя определяет техническое задание
|
|
+
|
+
|
+
|
выполнение стандартной работы
|
исчерпывающее ТЗ
составляется Клиентом
|
В первом случае крайне важно, чтобы консультант был полностью интегрирован внутрь организации, включая все необходимые полномочия и ответственность, при этом он должен «сложить» все свои оставльные (внешние) полномочия и ответственность, что резко повысит вероятность нахождения и внедрения оптимального для организации решения.
Во втором случае интеграция консультанта необязательна, хотя и желательна, при этом нужно отметь, что и в первом и во втором случаях не видно явной причины для привлечения консультанта, такой причиной может стать предполагаемый высокий опыт «около» данной проблемы, близость консультанта к внутренней «кухне» организации и многое другое, нужно или нет здесь привлекать и кого привлекать — достойные отдельной статьи вопросы.
В третьем случае консультант выступает в роли эксперта и на нем ответственность за разработку и аргументацию технического задания. Повторюсь, что в этом случае консультант может гарантировать результат от своей работы, иначе это первый или второй случай.
В четвертом случае внешний консультант может помочь заказчику «увидеть» известное, но по каким-то причинам еще невидимое решение. То есть катализировать, фасилитировать и прочее. Часто для обозначения этого типа консультирования используют термин «процессный консалтинг», однако, на мой взгляд, этот термин не очень красив, так как пересекается по смыслу и консультированием по оптимизации бизнес-процессов.
В этом четвертом случае нужно изменить задачу для консультанта, чтобы она перешла к третьему или пятому случаю. Как это сделать? Поставить задачу именно в том виде, в каком консультант специалист — ускорение процесса принятия решений.
В пятом случае заказчик поручает исполнителю стандартизованную работу, у которой известен не только результат, но и четко определен процесс выполнения. В этом случае техническое задание может и должен сделать заказчик, чтобы исключить ненужное творчество и чтобы выйти за рамки существующих технологий, стандартов и решений, которые уже наработаны в компании заказчика в этой области.
Фото: pixabay.com
1. Поди туда, не знаю куда, принеси то, не знаю что.Или, как вариант, по Л.Филатову - 'А изволь ка мне добыть то, чего на белом свете вообще не может быть'. Сам проект при такой постановке - уже бред. За который ни консультант не должен браться, ни клиент платить. Т.е. minimum minimorum, клиент должен задачу (цель) сформулировать, хотя бы в общих чертах.2. Плохой консультант, коли не знает решения. Или хотя бы сформулировать цели и задачи 'глобально'.3. На то и консультант, чтобы знать, КАК решить задачу клиента, начав с того, чтобы помочь преобразовать 'примерное видение общих целей' в конкретику для клиента.4. Консультант не знает решения, но знает клиент? Зачем тогда такой консультант нужен? Для технической работы - пардон, но чертёжник 'несколько' отличается от конструктора, и если есть сильное желание отдать такую работу на outsource - мне трудно понять такого клиента.5. Такая ситуация - почти нонсенс: если клиент пишет ТЗ сам, то уж никак не для консультанта, а лишь выдавая задание на ИСПОЛНЕНИЕ (а не консультирование) конкретной задачи. Соответственно, на 'внешней' стороне не консультант, а исполнитель. Что не одно и то жеP.S. Впрочем, весьма странные метаморфозы можно наблюдать на современном рынке 'консалтинга'...
В таблице рассмотрены 5 вариантов. А всего может быть 8 ( 2 в степени 3 ). Значит статью можно ещё доработать.………………………..Формулировка вопроса: Кто составит ТЗ ?Ответы – по порядку:1. Обычная область существования ответа – 2 стороны: заказчик и исполнитель.В отношении выдачи ТЗ сомнений – нет. [COLOR=red]Заказчик выдаёт[/COLOR] ТЗ исполнителю. В отношении разработки ТЗ – возможны варианты. Но, опыт показывает, что ТЗ формулируется на основе концепции его выполнения. А последней владеет исполнитель. Да и с точки зрения менеджмента, даже в случае компетентности заказчика, прямое участие исполнителя в составлении ТЗ является необходимым. Поэтому, лучше согласиться, что ТЗ составляет исполнитель. И включить это отдельным пунктом в перечень работ по договору.2. Автор статьи расширяет область существования ответа до 3-х сторон: заказчик, консультант, исполнитель. Тем самым противореча здравому смыслу; который прямо предписывает сторонам известные действия.3. Но, что, если консультант действительно является субъектом ситуации? Что ж, это – возможно. Если консультант «играет» за одну из сторон. Являясь её представителем. Так что, этот вариант, по сути, не отличается от первого.
Тяжелое впечатление от статьи.Хотелось бы понять, для какой аудитории она писана? По логике она писалась для потенциальных заказчиков. Тогда её должен был бы писать какой-нибудь консультант. Но статья не оставила чувства того, что она написана консультантом. Она мне показалась слишком путаной, в изложении плохо просматривается логика. Опять же автор так оперирует понятиями 'консультант' и 'исполнитель', что не поймешь: это одно или разные лица. Я так понимаю, по предыдущим высказываниям, что такое чувство сформировалось не только у меня.Еще один вопрос. Когда автор использует понятие 'Техзадание', то что он имеет в виду? Я видел в жизни разные документы, которые их составители пытались выдать за ТЗ. В них область проблем ('ЧТО система должна делать и/или ДЛЯ ЧЕГО использоваться') смешивалась с областью решений (КАК и/или ЗА СЧЕТ чего система будет что-то делать и/или как-то использоваться). Поэтому правильнее было начать с четкой формулировки понятия дабы люди несведующие четко понимали смысл понятий. Кстати, у меня от статьи сложилось впечатление, что и автор смешивает в понимании ТЗ области проблем и решений.Лично я так бы ответил на поставленный статьей вопрос:'Кто пишет техзадание?': т.к. техзадание представляет набор требований из области проблем, то писать его должен заказчик (если у него есть квалифицированные специалисты) или консультант (заказчик, естественно, утверждает ТЗ). Хотелось бы подчеркнуть, что роль консультанта при формировании техзадания заключается в том, чтобы в этом документе максимально точно были отражены проблемы, ключевые требования и ограничения проекта. Консультант на этом этапе выбирается не среди экспертов предметной области, а среди специалистов, умеющих извлекать потребности и знания из подсознания 'заказчика'.А вот консультант-эксперт в предметной области заказчику понадобиться, когда придет черед описывать видение решения задачи и разрабатывать или оценивать техпроект.Что касается написания техзадания исполнителем, да, на практике такое нередко встречается. В этом случае заказчик должен четко осознавать, что задание исполнителем будем максимально подогнано под себя, и учитывать это в оценке рисков проекта.Примечание: сомневающимся в моей трактовке техзадания предлагаю ознакомиться, например, с работами Г. Буча, Э. Халл, К. Джексона, К.Вигерса
[b]Александр Демьянов,[/b] за книженцию спасибо... приступил к поиску...прочту и, если интересно, вышлю комментарий - может будет что обсудить...
1. Поди туда, не знаю куда, принеси то, не знаю что.
Или, как вариант, по Л.Филатову - ''А изволь ка мне добыть то, чего на белом свете вообще не может быть''.
Сам проект при такой постановке - уже бред. За который ни консультант не должен браться, ни клиент платить. Т.е. minimum minimorum, клиент должен задачу (цель) сформулировать, хотя бы в общих чертах.
2. Плохой консультант, коли не знает решения. Или хотя бы сформулировать цели и задачи ''глобально''.
3. На то и консультант, чтобы знать, КАК решить задачу клиента, начав с того, чтобы помочь преобразовать ''примерное видение общих целей'' в конкретику для клиента.
4. Консультант не знает решения, но знает клиент? Зачем тогда такой консультант нужен? Для технической работы - пардон, но чертёжник ''несколько'' отличается от конструктора, и если есть сильное желание отдать такую работу на outsource - мне трудно понять такого клиента.
5. Такая ситуация - почти нонсенс: если клиент пишет ТЗ сам, то уж никак не для консультанта, а лишь выдавая задание на ИСПОЛНЕНИЕ (а не консультирование) конкретной задачи. Соответственно, на ''внешней'' стороне не консультант, а исполнитель. Что не одно и то же
P.S. Впрочем, весьма странные метаморфозы можно наблюдать на современном рынке ''консалтинга''...
В таблице рассмотрены 5 вариантов. А всего может быть 8 ( 2 в степени 3 ). Значит статью можно ещё доработать.
………………………..
Формулировка вопроса: Кто составит ТЗ ?
Ответы – по порядку:
1. Обычная область существования ответа – 2 стороны: заказчик и исполнитель.
В отношении выдачи ТЗ сомнений – нет. [COLOR=red=red]Заказчик выдаёт[/COLOR] ТЗ исполнителю. В отношении разработки ТЗ – возможны варианты. Но, опыт показывает, что ТЗ формулируется на основе концепции его выполнения. А последней владеет исполнитель. Да и с точки зрения менеджмента, даже в случае компетентности заказчика, прямое участие исполнителя в составлении ТЗ является необходимым. Поэтому, лучше согласиться, что ТЗ составляет исполнитель. И включить это отдельным пунктом в перечень работ по договору.
2. Автор статьи расширяет область существования ответа до 3-х сторон: заказчик, консультант, исполнитель. Тем самым противореча здравому смыслу; который прямо предписывает сторонам известные действия.
3. Но, что, если консультант действительно является субъектом ситуации? Что ж, это – возможно. Если консультант «играет» за одну из сторон. Являясь её представителем. Так что, этот вариант, по сути, не отличается от первого.