Как плохое ТЗ чуть не похоронило хороший проект

Любая новая идея в бизнесе зажигает глаза собственника. Я много раз видел, когда после длительных колебаний и переговоров, директор компании с огромным энтузиазмом смотрит на тех, кто делает что-то новое для этой компании. Звучат громогласные неконкретные фразы: «Вы же профессионалы», «Уверен, ребята, вы все сделаете», «Полностью вам доверяю, сделайте хорошо». А что дальше? Дальше начинается суровая реальность.

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

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

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

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

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

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

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

К этой истории мы еще вернемся, а пока к сути.

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

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

Что значит достичь цели? Давайте посмотрим на примере автомобиля. Я хочу купить авто, но буду ли я доволен, если куплю любой авто. Точно нет, потому что автомобиль как минимум должен быть исправен, иначе он просто не будет выполнять свою функцию, но только ли это меня интересует? Нет, еще это должен быть седан. Как на счет LADA Granta? Ничего не имею против, но может быть это будет что-то другое.

Уверен, вы уже догадались, к чему я клоню. Чем больше характеристик мы дадим, тем точнее наши ожидания будут соответствовать результату. Если бы задачу про авто я сформулировал как черный автомобиль не старше трех лет от немецкого производителя стоимостью от 2 500 000 до 3 000 000 рублей – это было бы уже более точное определение. А если добавить точную марку, модель комплектацию, цвет, адрес автосалона, страховую компанию, условия трейд ина, то картина приобрела бы максимальную жесткость.

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

При работе формулируйте, что для вас есть «Хорошо». Есть простое правило, которое работает максимально эффективно – критериев этого результата должно быть несколько, желательно от четырех и более. Если в итоге получится сформулировать по SMART, то в вашей постановке не будет цены, настолько она будет точной, но если все ожидания сводятся только к эмоциональной оценке, то никакой результат не будет в полной мере вас устраивать.

– Скажите, пожалуйста, куда мне отсюда идти?

– А куда ты хочешь попасть? – ответил Кот.

– Мне все равно – сказала Алиса.

– Тогда все равно, куда и идти, – заметил Кот.

– Только бы попасть куда-нибудь, – пояснила Алиса.

– Куда-нибудь ты обязательно попадешь, – сказал Кот. – Нужно только достаточно долго идти.

Льюис Кэррол. «Алиса в стране чудес»

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

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

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

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

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

После двухчасового разговора задача была сформулирована, а самое главное – было достигнуто точное понимание. Фактически не так много пришлось изменять, так как наши точки зрения оказались очень близкими на проект, но мы сэкономили значительное количество времени и внесли в дальнейшем только пару корректировок.

При формулировании задач старайтесь всегда давать максимальное количество характеристик, лучше чрезмерно подробно описывать свои цели, пусть 80% их окажутся очевидными для вашего подрядчика, но оставшиеся 20% будут очень полезны. Даже если на первоначальном этапе это займет какое-то время, то потом сэкономит вам значительный объем ресурсов.

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

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

Расскажите коллегам:
Комментарии
Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Прошел я по ссылке «Любой проект стоит начинать с максимального описания результата» (http://www.e-xecutive.ru/management/itforbusiness/1630040-kak-razrabotat-tehnicheskoe-zadanie-dlya-avtomatizirovannoi-sistemy).

Это ссылка на наиболее обстоятельную Е-хе-статью по ТЗ для IT-заказов. И дискуссия по ней была интересная. В ней я проявил необычайную писучесть. Поскольку, были времена, когда эта тема меня задевала существенно. С тех времён я понял, что для разработки рабочего проекта необходимо не только ТЗ, но и ЭП (разработанное силами заказчика!); и наиболее подходящим источником разработки ТЗ является ЭП. Причины необходимости ЭП – следующие:

  1. ЭП обеспечивает общее представление о конечном результате проекта и пути достижения результата.
  2. ЭП обеспечивает взаимоувязанность и непротиворечивость элементов п.1.
  3. ЭП является наиболее состоятельным-обоснованным источником исходных данных для разработки ТЗ.
  4. ЭП является общим источником информации для всех участников разработки рабочего проекта и всех участников команды проекта со стороны заказчика.
  5. ЭП даёт комплексное и актуальное представление о конечном результате проекта. Именно эта комплексность и описание путей достижения результата проекта, отличает ЭП от «калейдоскопа» Agile-моделей.

Кстати, после краткой характеристики ЭП, я могу точно сформулировать причину своего отрицательного отношения к Agile. Причина в «разобщенной калейдоскопичности» моделей Agile и в «кукушачьем характере» Agile.

Как из ЭП извлечь исходные данные для разработки ТЗ? Здесь вспомним о показателях назначения и показателях потребления объекта проектирования. Вот они-то и являются основными исходными данными для разработки ТЗ.

Кстати. Интернет знает только «показатели назначения» продукции; «показатели потребления» – не знает. Поэтому, приведу примеры показателей потребления. Это: габариты объекта-изделия; его вес; энергопотребление; показатели необходимого обслуживания; и т.д..

В общем, показатели потребления – это показатели того, что требуется для объекта-изделия, чтобы оный выполнял своё назначение. Вот, назначение автомобиля – перевозка пассажиров-грузов. А бензин-солярка и инфраструктура обслуживания-ремонта автомобиля – относятся к потреблению автомобиля.

В советские времена, касаясь разработок ТЗ, я заметил, что ТЗ на объект следует из представления о том, как создать объект. Но, назначение ЭП и состоит в описании того, что представляет собой объект и как его предполагается создать. Именно поэтому, разработку ЭП (силами заказчика!) я считаю абсолютно необходимой. Хотя, повторюсь, существуют серьёзные причины саботировать разработку ЭП. И потому, она саботируется повсеместно. Хотя для сложных проектов она требуется нормативно (правда, НЕ силами заказчика).

Консультант, Украина

Пока толстый сохнет - худой сдохнет.

Бизнес-продукт на Аджайле начнет находить бизнес-отзывы, а ваш допотопный мамонт устареет наполовину в момент релиза.


Специалист, Санкт-Петербург

Собрать группу специалистов под проект решение, которое позволит прозрачно соблюсти баланс деньги+время+качество для обеих сторон.

Ожидания клиента по старинке: у разработчика есть все супер-классные специалисты в штате на зарплате. И клиент приходит, чтобы разразиться пламенной речью, и разработчик погружается в бизнес клиента и "креативит".
Цена такого решения ?
коллега упомянул agile-разработку, но готов ли клиент платить?

Такие компании есть, но здесь похоже речь идет о массовом клиенте среднего ценового сегмента.
С чем приходится работать:

- бессмертный миф о всеобщей и тотальной бесплатности в интернете

- твердое убеждение клиента, что он лучше знает, как надо

- и самое ужасное - в дизайне разбираются все, даже уборщица клиента

- часто клиент находит время посмотреть только последниий вариант

Разумеется, часть возражений снимается "вам шашечки или ехать?"

Есть клиенты, от которых лучше сразу отказаться, тут и 1000 пунктов не помогут.
НО у заказчика люди в штате , стоимость привлечения клиента высока , вот и берутся за все подряд.

Вариант, если все же клиент готов участвовать в процессе

- нанять специалиста, который будет отстаивать интересы клиента перед разработчиком

- или будет искать разработчиков на каждый этап.


2
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.