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

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

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

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

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

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

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

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

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

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

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

На таком «зрелом» этапе мы можем увидеть другую картину — попытки оставить весь цикл разработок и производства в рамках одной компании уже не дают эффект (требуемый уровень качества уже достигнут), а затраты на поддержание такой интегрированной системы огромны и не окупаются. Как следствие, такая компания обречена проиграть в себестоимости и уступает долю рынка более стандартым продуктам (например, 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
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Хороший пример конспирологии. Есть реальные примеры? Просьба заодно уточнить, что такое "не понр...
Все дискуссии
HR-новости
Больше 70% россиян работают по выходным и во время отпуска

97% россиян регулярно задерживаются на работе.

В каких городах России наибольший прирост вакансий

В целом по России спрос работодателей за год вырос на 36%.

Исследование: какую зарплату хотят получать россияне

Пожелания по заработной плате мужчин и женщин коррелируются в зависимости от возраста соискателей.

80% работодателей отмечают нехватку квалифицированных работников

В целом слишком долгое закрытие вакансий волнует 45% представителей бизнеса.