Какой главный признак хорошего технического задания?
На заре своей карьеры я работал конструктором радиоэлектронной аппаратуры. Я тогда сделал свой первый проект - блок питания электронного компаса для скоростного военного корабля и пришел со сборочным чертежом к ведущему конструктору, чтобы он поставил на чертеже свою подпись. Я был абсолютно уверен в том, что все сделал правильно. Но руководителю понадобилось примерно 2 секунды, чтобы указать на грубую ошибку.
- У тебя на проводах под напряжением стоит вилка. Если клемма раскроется, то провод упадет прямо на стальную палубу и закоротит его.
- В смысле? - я стремительно перебирал в голове варианты где и что я не учел.
- Поменяй розетку и вилку местами на кабеле, который соединяет блок питания и компас.
- Но в техническом задании сказано сделать именно так! - ответил ему я.
- Ну и что, головой думать надо, а не только ТЗ читать. И ошибки в ТЗ надо исправлять. - здраво ответил мне ведущий конструктор.
Но совет “думать головой” слишком общий, и в этом видео я расскажу про конкретный мыслительный прием, который поможет избежать множества ошибок, которые возникают в ходе постановки и решения сложных нетиповых задач.
Базовый механизм мышления заключается в создании различений, классификаторов. Мы отличаем мужчин от женщин (хотя все люди), выручку от прибыли (хотя все это деньги), потенциальных покупателей от лояльных клиентов (хотя и те и те - причина существования бизнеса).
И если мы говорим про системное управление проектами, то базовым различением, на которое опирается все наше мышление, является система и ее контекст. В примере с розеткой была система блока питания и контекст использования этой системы - стальная палуба корабля.
Критически важное требование поменять розетку и вилку местами пришло именно из знания и понимания контекста ведущим конструктором. И хорошее техническое задание всегда схватывает ключевые элементы контекста на пять с плюсом.
В моей практике были и куда более показательные случаи чем этот, когда знание и понимание контекста приносило людям большие деньги, авторитет у заказчика и перспективы развития бизнеса.
Но видеть систему и контекст в своих проектах я научился далеко не сразу.
КЕЙС
Один из первых проектов, в котором я участвовал в роли руководителя, была контрактная разработка и поставка системы интеллектуального светодиодного освещения для промышленных теплиц. Наша компания получила грант на несколько миллионов Евро на разработку и создание этой системы. Изначально проект казался типовым - еще одна система освещения, которых мы спроектировали уже десятки.
Идея заключалась в том, что растения хорошо улавливают лишь две части спектра излучения - голубой свет и красный. Я думаю, многие видели специальные сине-красные лампы для растений, это они. И получается, что остальные части спектра, которые есть в обычных лампах, куда менее полезны с точки зрения роста растений, а затраты электроэнергии в традиционных системах освещения не самые оптимальные.
Это почти как со спортивным питанием - если много и правильно заниматься, но питаться как обычно, то рост мышечной массы будет идти куда медленнее, чем если потреблять изоляты белков и куриные грудки. Вот мне и надо было сделать такую систему освещения, которая бы кормила растения только куриными грудками, без пирожных и французских батонов. Это была функция моей системы.
Я взял техническое задание с похожего проекта, переделал его под наши нужды, и пошел сдавать его заказчику. Но сдать с первого раза не получилось, потом не получилось сдать второй раз, третий. Прошел целый месяц, а я по прежнему получал замечания на доработку. Затем подошел дедлайн по запуску проекта, я был на грани отчаяния. Если проект не стартует, то компания теряет перспективный заказ, грант, а меня ждет позорное увольнение.
Я стал искать помощи. В конструкторском отделе сидел опытный инженер-конструктор, который собаку съел на проектировании, ЕСКД, ЕСТД, СПДС и ЕСПД. Я отправил ему техническое задание с комментариями заказчика ему и попросил помочь. Он позвонил уже через полчаса и предложил подойти к нему.
СУТЬ ПРОБЛЕМЫ
При встрече эксперт сказал такую штуку.
- Вы в вашем ТЗ постоянно пытаетесь описать то, как система будет устроена внутри. Не надо так делать. Представьте ее “черным ящиком” и представьте, что вы продаете этот “черный ящик” заказчику. Кто у вас заказчик - агрокомбинат? Ну вот, у них уже есть работающая теплица, которую вы оснащаете своей системой. Что эта система делает, когда ее внедряют в тепличный комплекс? С какими частями тепличного комплекса она связывается, к чему подключается, какие параметры этих подключений?
- Мы за полчаса на флипчарте нарисовали картинку, где квадратик системы интеллектуального освещения соединялся с частями теплицы. И с каждой минутой этой консультации ко мне приходила все большая ясность, я стал понимать, где мы налажали, где были правы, а какие решения слишком рискованны, чтобы класть их на бумагу и заверять печатью и подписью. Я, наконец, понимал всю критику заказчика и был полностью с ней согласен. Видимо, при чтении проекта ТЗ и в разговорах со мной руководитель проекта со стороны заказчика всегда представлял себе контекст агрокомбината и пытался вписать в него предлагаемое нами решение. А когда не получалось, давал замечания.
Я повеселел и ободрился, а эксперт смотрел на меня с улыбкой.
- Вот это называется “контекстная диаграмма”, без нее лучше никакое, даже самое простое техническое задание не делать, - напутствовал меня он. - А по шаблону ТЗ лучше не делать никогда, понимаете? Все проекты уникальны, и если у вас нет по-настоящему похожего по контексту использования примера технического задания, то надо разрабатывать документ с нуля, а не пытаться натянуть применение на имеющийся неподходящий шаблон.
РЕШЕНИЕ
Контекст даже небольшой и несложной системы может быть довольно сложным, особенно, если предметная область вам плохо знакома, и без описания этого контекста хотя бы на листке бумаги вам не обойтись. Вы должны четко разделить систему и ее окружение, описать взаимодействие между системой и элементами этого окружения, которые важны для выполнения системой своей функции и исполнения назначения. Это беспроигрышный первый ход в любом проекте, который в худшем случае прояснит неясности, а в лучшем спасет вашу карьеру и кучу денег вашему клиенту и работодателю.
МЫСЛИТЕЛЬНЫЙ ХОД
Поэтому если вы выделяете и описываете систему, то обязательно выделяйте и описывайте ее контекст. Это различение является базовым в системном подходе. Контекст - это та часть системного окружения, которая важна для выполнения функции, назначения системы, то без чего она не будет работать. Например, для автомобиля заправка, центр техобслуживания, дорога и GPS будут частью контекста. Если вы создаете автомобиль, нельзя не учесть их существование.
В ЧЕМ ПОЛЬЗА
Разделение системы и контекста - это невероятно простой, но чрезвычайно мощный прием мышления при управлении проектами. Чем лучше вы выполняете этот прием, тем больших результатов вы достигаете, тем более четкими, ясными и понятными для руководства, коллег и партнеров становятся ваши действия и принимаемые решения. И все это формирует вашу репутацию как руководителя, которому можно поручить критически важный проект.
Когда я хожу по улицам, выезжаю в полевые визиты, хожу по магазинам и торговым центрам, заводским цехам, мастерским, офисам, я всегда стараюсь понять, какие системы там есть, где проходят их границы, как они взаимодействуют, в чем их польза. Это наполняет даже скучную и рутинную работу по сбору информации для дальнейшего анализа или для подготовки к переговорам смыслом и пользой. А с другой стороны понимание контекста, привязка к нему моих рекомендаций заставляет людей прислушиваться к этим рекомендациям, потому что они понимают, как конкретно применить эти рекомендации, видят их предметность и конкретику.
ЧЕМУ НАДО УЧИТЬСЯ?
Чтобы правильно, полно и точно описывать контекст, надо учиться 3 вещам:
- моделированию предметной области,
- анализу контекста,
- построению объяснительных и предсказательных моделей.
Я описываю контекст в четыре шага.
Ранняя диагностика. В первую очередь я выясняю, какой бизнес-процесс меняет заказчик и какую проблему он в нем видит. Обычно это выясняется в первые пять минут разговора, поэтому надо быть очень внимательным к тому, что говорится вначале. В случае с теплицей это был процесс выращивания растений, а проблема заключалась в необходимости снизить потребление электричества процессом и невозможности дальнейшего снижения с помощью имеющейся технологии.
Целевое состояние. Заказчику нужны были овощи и цветы с более низкой себестоимостью, при этом без ухудшения качества. Истинной потребностью заказчика была технология, которая бы позволяла это делать.
Описание проекта. После того, как мы поняли, что на самом деле надо заказчику, мы смогли оформить правильное техническое задание и эффективно организовать проект.
Анализ системных взаимодействий. И уже понимая цель и организацию, нам было легко сделать анализ системных взаимодействий и дойти до конкретной реализации решения.
ИНТРИГА
Но на создании качественного продукта, который нужен заказчику или рынку, бизнес только начинается. В следующем ролике я расскажу, как один мой клиент закрыл успешный пилотный контракт на создание продукта, получил следующий контракт, уже на масштабирование решения, но его ожидания от проекта сильно не оправдались - компания делала все, как говорил Заказчик, но вместо денег получали только жалобы, и срывы обещаний по количеству внедрений.
В чем же было дело и что произошло дальше? Ответ будет в следующем ролике “Имплементация”. Подписывайтесь на мой канал, ставьте лайки и пишите свои вопросы в комментариях, я обязательно на них отвечу.
Комментариев нет:
Отправить комментарий