Любая новая идея в бизнесе зажигает глаза собственника. Я много раз видел, когда после длительных колебаний и переговоров, директор компании с огромным энтузиазмом смотрит на тех, кто делает что-то новое для этой компании. Звучат громогласные неконкретные фразы: «Вы же профессионалы», «Уверен, ребята, вы все сделаете», «Полностью вам доверяю, сделайте хорошо». А что дальше? Дальше начинается суровая реальность.
Осенью 2014 года к нам обратился клиент по рекомендации, его партнеру мы сделали хороший проект по продвижению сайтов, поэтому на повышенном эмоциональном фоне, мне позвонил этот новый клиент. Суть его бизнеса заключалась в продаже товаров, который он производил на контрактованном производстве в Китае, а энергии было хоть отбавляй. За несколько лет работы он с минимальным штатом в 3 человека сделал очень достойный результат.
Если кратко описать его стратегию, то она сводилась к постановке перед людьми большой амбициозной цели, накачкой этих людей энергией и отступление на позицию стороннего наблюдателя. Кроме того, харизма этого человека была достойна изучения в институтах по лидерству.
Наша первая встреча прошла очень ярко, мы обсуждали цели их компании, какую роль будет играть проект в их дальнейшем развитии, все это было максимально общо, но очень зажигало. Так как действительно хотелось сделать не просто на отлично, а на пять с плюсом, то было решено с нашей стороны подключить все ресурсы компании.
Через пару недель переговоров началась работа, сначала разработали стратегию продвижения, потом преступили к дизайну, все это было решено кратко обсуждать. Фокус был только на том, что наши новые продажи через сайт должны все изменить, поэтому фактически все работы проходили без правок и, казалось, что это просто идеальный проект и идеальный ход работ.
Через полтора месяца после начала проект был завершен, и мы предоставили его на финальное тестирование. И тут сценарий немного поменялся, впервые мы получили отрицательную обратную связь, потому что дизайн должен совпадать максимально с тем, что есть сейчас на сайте, потому что иначе узнаваемость теряется.
Мы вернули проект в работу, полностью изменили дизайн, сделали его максимально схожим, но в рамках современных трендов, еще раз провели его через все стадии верстки и программирования и через 2 недели предложили новый вариант на рассмотрение, потому что после этого случая и на фоне общего фона, я был уверен: проект теперь точно идеален, потому что та единственная проблема со схожестью дизайна была исправлена.
В ответ я получил еще один негативный комментарий: а почему мы используем именно такое расположение элементов в административной панели, все должно быть совсем иначе, продумайте новый интерфейс. Я понимал, что у меня есть точное понимание и опыт как надо, а с другой стороны неожиданные комментарии клиента, и если сейчас мы переделываем все еще раз, то еще одна ошибка и наша репутация начинает уходить в отрицательное исчисление. Говорить уже о какой-то прибыли по этому проекту вообще не приходилось.
К этой истории мы еще вернемся, а пока к сути.
Я уверен, что оптимизм это одно их ключевых качеств в бизнесе, потому что, когда с одной стороны, есть негативное отношение к предпринимательству, с другой стороны – бесчисленное количеств проблем, то быть пессимистом и работать в бизнесе в России, практически невозможно. Поэтому зачастую предприниматели, с которыми мне приходилось общаться, оптимистичные люди. У каждого есть свои особенности, но вера в успех, и понимание того, что все получится либо так, либо как-нибудь иначе, есть у каждого. И это очень ценно. Я убеждался много раз, что если начинать дело исходя только из расчетов, но без веры в успех – ничего не получится.
На каждый новый проект мы смотрим как на новую возможность, как на то, что изменит все вокруг нас, ну или если не все, то очень многое, каждая инвестиция принесет нам деньги, достижение целей или шаг к чему-то большему, но, к сожалению, все мы разные… Поэтому, что «хорошо» для одного, это «so-so», как говорят наши американские партнеры, для другого.
Что значит достичь цели? Давайте посмотрим на примере автомобиля. Я хочу купить авто, но буду ли я доволен, если куплю любой авто. Точно нет, потому что автомобиль как минимум должен быть исправен, иначе он просто не будет выполнять свою функцию, но только ли это меня интересует? Нет, еще это должен быть седан. Как на счет LADA Granta? Ничего не имею против, но может быть это будет что-то другое.
Уверен, вы уже догадались, к чему я клоню. Чем больше характеристик мы дадим, тем точнее наши ожидания будут соответствовать результату. Если бы задачу про авто я сформулировал как черный автомобиль не старше трех лет от немецкого производителя стоимостью от 2 500 000 до 3 000 000 рублей – это было бы уже более точное определение. А если добавить точную марку, модель комплектацию, цвет, адрес автосалона, страховую компанию, условия трейд ина, то картина приобрела бы максимальную жесткость.
К постановке задач и их контролю я буду возвращаться очень часто, потому что это является одним из ключевых условий при работе IT, так как вариантов реализации бесконечное множество, и все они будут приносить пользу, но эта польза будет разная.
При работе формулируйте, что для вас есть «Хорошо». Есть простое правило, которое работает максимально эффективно – критериев этого результата должно быть несколько, желательно от четырех и более. Если в итоге получится сформулировать по SMART, то в вашей постановке не будет цены, настолько она будет точной, но если все ожидания сводятся только к эмоциональной оценке, то никакой результат не будет в полной мере вас устраивать.
– Скажите, пожалуйста, куда мне отсюда идти?
– А куда ты хочешь попасть? – ответил Кот.
– Мне все равно – сказала Алиса.
– Тогда все равно, куда и идти, – заметил Кот.
– Только бы попасть куда-нибудь, – пояснила Алиса.
– Куда-нибудь ты обязательно попадешь, – сказал Кот. – Нужно только достаточно долго идти.
Льюис Кэррол. «Алиса в стране чудес»
Эта цитата должна быть в любом учебнике по менеджменту выбита золотыми буквами, потому что любому менеджеру она позволила бы избежать десятков и сотен ошибок, если бы всегда была перед глазами. Хорошо – это практически все равно как, потому что из нее никому и ничего непонятно.
Вернусь к моей истории – я понимал, что ситуация снова вернется в это же русло, если мы просто внесем корректировки по последней обратной связи, и что это только вершина айсберга, поэтому предложил такое решение: выделить два часа времени и точно описать в мельчайших подробностях что будет являться результатом, а что точно будет являться неверным решением. Очень рад, что в этом вопросе нам удалось достичь понимания.
За эти два часа мы узнали очень многое о проекте, в принципе мы решили написать 100 пунктов того, что есть хороший результат, в этом списке были и задачи, которые он решает, и цвета, которые использованы, и похожие решения, и многое другое. Потом записали еще 50 пунктов того, что будет являться плохим результатом и чего нужно избегать. Знаю, что многие психологи рекомендуют избегать негативных постановок, но для таких проектов считаю, что это очень полезно.
Любой проект стоит начинать с максимального описания результата – многие не любят описывать очевидные вещи, но чем больше мы работаем, тем больше понимаем, что нет типовых задач и стандартных решений, потому что всегда есть особенности вашей фирмы, сотрудников, ваших клиентов или продукта.
Чем больше деталей и описания конечного результата будет изначально, тем точнее будет понимание того как действовать, меньше корректировок вносить и какие ресурсы использовать.
После двухчасового разговора задача была сформулирована, а самое главное – было достигнуто точное понимание. Фактически не так много пришлось изменять, так как наши точки зрения оказались очень близкими на проект, но мы сэкономили значительное количество времени и внесли в дальнейшем только пару корректировок.
При формулировании задач старайтесь всегда давать максимальное количество характеристик, лучше чрезмерно подробно описывать свои цели, пусть 80% их окажутся очевидными для вашего подрядчика, но оставшиеся 20% будут очень полезны. Даже если на первоначальном этапе это займет какое-то время, то потом сэкономит вам значительный объем ресурсов.
Самым простым вариантом будет выключить телефон, интернет и все, что может отвлекать и просто написать 100 пунктов того, что такое для вас результат в рамках продвижения сайта, разработки, поддержки или еще чего-нибудь, после того как закончатся очевидные вещи вам ничего не останется, как перейти к сути вопроса. Кроме того, в рамках этой работы вы сможете понять, а нужно ли вам вообще такое решение, иногда при формулировании мы приходим к выводу, что достигнутый результат не даст нам никакой пользы.
У нас у каждого свое понимание хорошего, так что не скупитесь потратить немного времени на то, чтобы описать то, чего вы хотите и тогда результат будет в полной мере соответствовать вашим ожиданиям.
101-ая статья о крайней необходимости написания качественного ТЗ, BRD или ПЗ (постановки задачи).
Для тех, кто в теме - это всё очевидно и элементарно. Всем остальным это неважно, потому что учатся на своих ошибках и родных граблях. И не Кэрролл тут в тему, а простое "хочешь, чтобы было сделано хорошо - сделай сам". За доверием к исполнителю всегда стоит лень заказчика, отстраняющегося от участия словами "ну я вам доверяю, как эксперту-профессионалу".
По-моему сейчас уже даже ремонт в квартире силами наёмных бригад так не делают. Каждый этап нужно контролировать.
Интересно, кому-нибудь удавалось подписать с заказчиком ТЗ на сайт, которое:
1. Сделано по 34 ГОСТу
2. Не допускает разного понимания
3. При любом выполнении всех пунктов результат будет полностью соответствовать ожиданиям Заказчика.
Диагноз поставлен верно, а вот лекарство назначено неправильно. Современные методы лечения болезни несоответствия итогового продукта ожиданиям потребителя -- особенно в IT-сфере -- предлагают Agile-подход как альтернативу попыткам зафиксировать и прописать все детали задания до начала проекта. Минимизация времени получения первых версий продукта (fail fast), регулярный фидбэк от заказчика, адаптация значительно увеличивают вероятность выздоровления. Те, кто изучал теорию автоматического управления, знают, что качество управления существенно зависит от параметров обратной связи.
Идея же о том, что заказчик изначально в деталях представляет, чего он хочет -- надо лишь как следует расспросить -- обычно не находит отражения в действительности. Не говоря уже о более сложных случаях протекания болезни, когда потребности меняются по ходу создания продукта.
Уверен, что нет. ТЗ с IT это целая лебединая песня. Начиная от разницы в сленге и заканчивая в желаниях. Зачастую необходим посредник дабы заказчик понял IT и наоборот. У же не говоря об качестве исполнения. Есть индивиды которые пишут нормальные сайты и стоимость намного ниже, а часто бывает, нанимают команду, платишь..., а получаешь хуже чем у одиночки, при одном и том же ТЗ. Недаром говорят 2 человека, 3 мнения, с IT, это спокойно можно умножить на два.
Автор обсуждаемой статьи пишет по делу, а не занимается «розливом воды». Так что, я не согласен с первыми двумя комментариями.
Автор пишет о «вечной» проблеме взаимопонимания между заказчиком и исполнителем, в части видения-представления ими будущего объекта. Причина этой непреходящей «вечности» – в недостаточности усилий-затрат на начальной стадии проектирования будущего объекта.
В советские времена, программы для выполнения инженерных расчетов я разрабатывал для себя сам. Некоторые из них содержали десятки подпрограмм-модулей. Чтобы меньше делать ошибок, я листал книги по теории и практике программирования. В нынешние времена, в разработках-осуществлении проектов строительных объектов, я выполнял обязанности ведущего разработчика + ГИП-а и (далее) руководителя проекта. Таким образом, могу сказать по опыту, что разработка-осуществление проектов IT-объектов и материальных объектов аналогичны в значительной степени. Поэтому, дальше буду говорить о разработке-осуществлении объектов строительства.
В промышленных проектах, создание необходимых новых производственных фондов – это, как правило, их проектирование и строительство. Объекты строительства визуально более доступны, чем IT-объекты. И достичь взаимопонимания по представлению первых, как будто, несложно. Тем не менее, на стадии ТЗ, представления заказчика и генподрядчика по проектированию различаются существенно. И эта разница неизбежно проявляется в результате проектирования – в рабочем проекте. И если заказчик не озаботился изучением рабочего проекта перед отправкой его «к производству работ», то разницу он увидит в построенном объекте.
В советские времена вышеуказанная разница отсутствовала. Потому что, проектировщики разрабатывали проект на всех его стадиях.
В нынешние времена, проектировщики локализовались только на последней стадии – на разработке рабочего проекта. И если выполняют предыдущие стадии, то особо ими не утруждаются (по причине их нерентабельности). Таким образом, эскизный проект (далее, ЭП) фактически выпал из разработки. А за ним рухнула и вся «вавилонская башня» проекта. Теперь проектировщики стремятся выполнить сразу рабочий проект. Они шустро пишут ТЗ, отражающее их представление об объекте. Заказчик «не глядя» подписывает ТЗ. И благодушествует издавая «громогласные неконкретные фразы: «Вы же профессионалы», «Уверен, ребята, вы все сделаете», «Полностью вам доверяю, сделайте хорошо»». Потом, по построенному объекту рассвирепевший заказчик предъявляет претензии к генподрядчику по проектированию. А тот отвечает: «Дык, мы сделали то, что Вы нам задали посредством ТЗ».
Разница представлений, указанная в предыдущих двух абзацах, устраняется-минимизируется следующими средствами:
Эти средства описываются-устанавливаются ГОСТ-ами. Пролистывая их, нетрудно заметить, что неотъемлемой частью содержания стадий являются соответствующие модели-макеты. Особо важное значение для установления взаимопонимания о строящемся объекте имеет его модель в виде ЭП. Не буду пересказывать известное из ГОСТ-а содержание ЭП. Скажу только следующее: я считаю абсолютно необходимым разрабатывать ЭП силами заказчика. Потому что, строительный объект определяется тем производством, которое заказчик предполагает в нём разместить.
В условиях наличия-присутствия вышеуказанной разницы в представлениях заказчика и исполнителя, абсолютно необходима тщательная апробация на заказчике результатов каждого шага разработки-осуществления проекта. Даже хуже. Заказчик всё равно «плавает» в представлении того, что ему нужно. Поэтому, особенно в начале процесса проектирования, нет смысла в деталях. Вместо них надо ставить «заглушки». И только после того, как заказчик своими руками проверит-утвердит работу текущей модели, имеет смысл переходить к разработке следующей, более детальной, модели заказанного IT-объекта. У меня это проявлялось в следующем: подрядчику по проектированию строительного объекта я предоставлял ЭП, в качестве исходных данных для разработки ТЗ и для последующей разработки рабочего проекта. При необходимости, последующие изменения исходных данных начинались с изменений в ЭП. Что помогало выявлять и избегать нежелательных побочных эффектов от изменений. Кстати, эта итеративность «классического» процесса проектирования советских времён, была в нынешние времена украдена и безграмотно раздута в виде "смарта" и "эгайла".
Практика предоставления ЭП в качестве исходных данных, приводила к удешевлению разработки рабочего проекта (где-то, на треть, относительно нормативных цен). Действительно, в ЭП объект строительства определяется почти полностью. И рабочее проектирование сводится к детализации решений ЭП. Таким образом, предоставление ЭП существенно снижало трудозатраты разработки рабочего проекта.
Но, скажу прямо, моя практика и мои прошлые сообщения о ней не поддерживаются «проектной общественностью». Основная причина – незащищенность результатов интеллектуального труда и (не будем ханжить) жлбство. Но, кидать камни в «жлобов» я не стану. Они вынуждены заботиться о своей незаменимости-защищенности. И для этого у них есть основания. В советские времена этих оснований было мало. В нынешние – слишком много. И посему, разработка ЭП будет упорно саботироваться. Так что, проблема взаимопонимания между заказчиком и исполнителем, в части видения-представления ими будущего объекта, будет «вечной». А значит, не иссякнет ручеёк статей, подобных обсуждаемой.
В порядке критического замечания к обсуждаемой статье, скажу следующее. Конечно, «написать 100 пунктов того, что такое для вас результат» – это хорошо. Но, лучше, если этот «сарай» исходных данных будет организованным, в виде ЭП.
Не совсем понятны жалобы автора в примере с созданием сайта.
Это его проблемы, что он на стадии согласования не спросил у заказчика, о его пожеланиях по дизайну и алгоритму работы навигации сайта.
А нытье про уход в минус при изменении навигации, это вообще нечто.
Мне навигацию люди меняли за 2 часа.
Это уже не первая подобная статья, о недопонимании при создании сайтов.
И как правило, проблема заключается не в заказчике, а в исполнителях. Т.к. они часто клепают сайты, как им привычнее и удобнее, а не так как хочется заказчику.
Если у специалиста есть голова на плечах и руки из нужного места растут, то внести озвученные корректировки в сайт, для него не проблема.
А если нет, то тут и появляются подобные статьи.
Поэтому, при создании своих сайтов я всегда пользуюсь услугами фрилансеров.
Выбираешь из их портфолио, что-то созвучное своему видению, озвучиваешь свои пожелания и вперед.
Из всего материала очень понравился подход Олега Шурина.Простое и эффективное решение.не надо ломать представления исполнителя, а находить близких по идеологии. Поэтому согласен в оценке самой статьи- 101 вариант российской ситуации- сначала включит прибор, а затем будет читать инструкцию.при этом еще и отягощенный желанием быстрей срубить баки, а не сделать работу нормально.
еще ни разу не видел ТЗ а котором адекватно прописана ЦГ и особенно в части чем она мотивирована, чтобы использовать еще одну кнопку в дополнение к существующим 100 000 000 кнопок
почему возможно изменение поведения ЦГ и включение в модель поведения очередного сервиса? Что такое должно происходить с ЦГ, чтобы их модель поведения изменилась?