Кто составит техзадание?

Заказчик хочет поручить сторонней организации (например, консультанту) решение некоторой проблемы (выполнение некоторой работы). Кто должен определить необходимый объем работ и перечень задач? Заказчик или исполнитель? Или может быть они должны совместно участвовать в формулировании «технического задания»?

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

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

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

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

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

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

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

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

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

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

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

Таблица 1. Варианты работы над техническим заданием

 

Существует надежное решение

 

 

Известно консуль-танту

 

 

Решение известно Клиенту

 

 

Форма работы консультанта над проблемой

 

 

Составитель техзадания (ТЗ) и форма постановки задачи

 

 

 

 

 

 

 

 

внутри организации, участие в поиске решения

 

 

общая формулировка проблемы уточняется в ходе работы над ней

 

 

+

 

 

 

 

 

 

участие в проекте выбора и внедрения

 

 

формулировка задачи подразумевает диапазон решений

 

 

+

 

 

+

 

 

 

 

участие в рабочей группе в качестве эксперта

 

 

ТЗ составляется консультантом,

 

 

утверждается Клиентом

 

 

+

 

 

 

 

+

 

 

участие в рабочей группе в качестве модератора

 

 

Клиент сам для себя определяет техническое задание

 

 

+

 

 

+

 

 

+

 

 

выполнение стандартной работы

 

 

исчерпывающее ТЗ

 

 

составляется Клиентом

 

 

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

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

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

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

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

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

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии

Тяжелое впечатление от статьи.
Хотелось бы понять, для какой аудитории она писана? По логике она писалась для потенциальных заказчиков. Тогда её должен был бы писать какой-нибудь консультант. Но статья не оставила чувства того, что она написана консультантом. Она мне показалась слишком путаной, в изложении плохо просматривается логика. Опять же автор так оперирует понятиями ''консультант'' и ''исполнитель'', что не поймешь: это одно или разные лица. Я так понимаю, по предыдущим высказываниям, что такое чувство сформировалось не только у меня.
Еще один вопрос. Когда автор использует понятие ''Техзадание'', то что он имеет в виду? Я видел в жизни разные документы, которые их составители пытались выдать за ТЗ. В них область проблем (''ЧТО система должна делать и/или ДЛЯ ЧЕГО использоваться'') смешивалась с областью решений (КАК и/или ЗА СЧЕТ чего система будет что-то делать и/или как-то использоваться). Поэтому правильнее было начать с четкой формулировки понятия дабы люди несведующие четко понимали смысл понятий. Кстати, у меня от статьи сложилось впечатление, что и автор смешивает в понимании ТЗ области проблем и решений.

Лично я так бы ответил на поставленный статьей вопрос:''Кто пишет техзадание?'': т.к. техзадание представляет набор требований из области проблем, то писать его должен заказчик (если у него есть квалифицированные специалисты) или консультант (заказчик, естественно, утверждает ТЗ). Хотелось бы подчеркнуть, что роль консультанта при формировании техзадания заключается в том, чтобы в этом документе максимально точно были отражены проблемы, ключевые требования и ограничения проекта. Консультант на этом этапе выбирается не среди экспертов предметной области, а среди специалистов, умеющих извлекать потребности и знания из подсознания ''заказчика''.
А вот консультант-эксперт в предметной области заказчику понадобиться, когда придет черед описывать видение решения задачи и разрабатывать или оценивать техпроект.
Что касается написания техзадания исполнителем, да, на практике такое нередко встречается. В этом случае заказчик должен четко осознавать, что задание исполнителем будем максимально подогнано под себя, и учитывать это в оценке рисков проекта.

Примечание: сомневающимся в моей трактовке техзадания предлагаю ознакомиться, например, с работами Г. Буча, Э. Халл, К. Джексона, К.Вигерса

Зверев Борис пишет: 1. Поди туда, не знаю куда, принеси то, не знаю что. Или, как вариант, по Л.Филатову - ''А изволь ка мне добыть то, чего на белом свете вообще не может быть''. Сам проект при такой постановке - уже бред. За который ни консультант не должен браться, ни клиент платить. Т.е. minimum minimorum, клиент должен задачу (цель) сформулировать, хотя бы в общих чертах.
Доброго времени суток, Борис. Бредовый проект - это поиск несуществующего решения. В некоторых случаях - неминуемая вещь ))) Задача существует в виде некоторой проблемы, но... Длинно не буду писать, а то рискую неправлильно процитировать Альтшуллера ))
Владимир Зонзов пишет: В таблице рассмотрены 5 вариантов. А всего может быть 8 ( 2 в степени 3 ). Значит статью можно ещё доработать.
Здравствуйте, Владимир. Спасибо за комментарий. Вариантов все-таки 5. Варианты, когда решения не существует а оно кому-то известно, - исключены ))))))
Владимир Зонзов пишет: 2. Автор статьи расширяет область существования ответа до 3-х сторон: заказчик, консультант, исполнитель. Тем самым противореча здравому смыслу; который прямо предписывает сторонам известные действия.
Вероятно, я был недостаточно внимателен при написании, что сложилось ощущение, что есть третья сторона. Ее нет. Про то, кто владеет концепцией, и кто проблемой вроде бы написал, но, вероятно, недостаточно ясно. Век живи, век учись.. )) Приношу извинения за проблемы чтения. Что, если по-простому сформулировать: 1 вариант - никто не знает решения - объединение специалистов разного профиля в поиске 2 вариант - решение есть, но Клиент и его консультант на пути к нему... несмотря на абсурдность - частое явление, особенно в России, хотя и в буржуйляндии - тоже встречается... 3 вариант - консультант владеет решением - он и составляет техзадание для себя - ЭТОТ ВАРИАНТ КОНСУЛЬТАНТЫ ОЧЕНЬ ЛЮБЯТ, но не всегда отдают себе отчет в том, действительно ли это третий вариант 4 вариант - Клиент владеет решением - он составляет техзадание (процессное консультирование как его называют всякие тренеры, коучи... помогают, вроде как, сформулировать решение, выродить его в группе..) 5 вариант - всем известно - типовая задача, строго описана - это как заказать печать визиток ))
Александр Демьянов пишет: Тяжелое впечатление от статьи.
Спасибо за прямоту, Александр. Прошу винить во всем меня, а не ''методику'' определения ответственного за техзадание. Проблема - у меня - с русским языком ))) Сама методика - не моя - я только перефразировал и перенес из другой сферы знаний )) она безупречно работает...
Олег Фофанов пишет: Прошу винить во всем меня, а не ''методику'' определения ответственного за техзадание.
Олег Фофанов пишет: Сама методика - не моя - я только перефразировал и перенес из другой сферы знаний )) она безупречно работает...
Дали бы ссылку на методику и мы бы поучились. ;) Возможно она и работает, но изложили вы ее сумбурно. Не знаю из какой сферы знаний вы ''свою'' методику вытащили, куда перетащили и зачем вы это делали. Рекомендую найти и почитать вот эту книженцию: ''Разработка и управление требованиями'', авторы Э.Халл, К.Джексон, Дж.Дик, ищите у компании Telelogic. Уверяю вас, изложенный там подход работает во всех сферах, его и перефразировать и адаптировать не надо, бери и пользуйся :)
Олег Фофанов пишет: Проблема - у меня - с русским языком )))
Это очень плохо для консультанта, но хорошо, что вы это понимаете. Тренируйтесь :)
Александр Демьянов, за книженцию спасибо... приступил к поиску...прочту и, если интересно, вышлю комментарий - может будет что обсудить...
2
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии