Протокол «сионских мудрецов», или Замечание об Инструкциях

Как это бывает

Вы хотите некое дело довести до успешного конца? Что, серьезно? И это не пикник за городом, а «серьёзный» проект на 3-4 месяца с участием пяти человек, пара из которых работают удаленно и в глаза друг друга не видели (хуже того, точно неизвестна их квалификация)? И на разработку продукта может уйти кругленькая сумма, да еще, есть чувство, с перерасходом, а за нею стоит кредитор с «большими зубами»? Вы плохо представляете объем работ и вообще, как все это точно реализовать? Вы не можете контролировать всех, потому как не представляете, что делает каждый участник («ах, он снова укатил на рыбалку, а проект не компилируется…»)? У вас нет достаточной квалификации, чтобы вообще понять, что вам прислал очередной программист? У вас трения в команде с самого начала? Или все друг другу мило улыбаются, но все совещания по Скайпу заканчиваются лишь руганью или распитием пива с чоканьем о сенсорный экран (поставьте галочки против вопросов)?

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

Итак, вы считаете это чушью и лишней тратой времени. Мол, управление проектом — бюрократия и удел «старых пер… совковых, либо западных фарисеев»? Тогда поберегитесь. Дело «не выгорит», а вот вы – прогорите. В лучшем случае, ваш «прожект» тихо помрет, и вы даже не поймете, в какой момент это произошло. Сначала пропадет один человек, незаметно так, даже не сдав последнего задания, потом второй… При этом у каждого окажется сто благовидных причин по поводу того, что произошло, и почему вы еще ему и денег должны, о которых впервые слышите. Но ведь и вы сами спохватитесь лишь через неделю, а то и две после того, как должны были получить от них результаты работы? Потом вы сами начнете уделять проекту меньше времени, и в какой-то момент обнаружите, что грезите уже совсем другой идеей, уговариваете соседа Мишку принять участие в новом «супер-прожекте на миллион», а о старом даже не думаете. И все начнётся по новой. Только вот с тем же самым результатом.

Может быть и хуже. Если вы заняли денег у знакомых, да еще и с темным прошлым, либо получили контракт у дистрибьютора или хотя бы простого клиента, или взяли в банке кредит, зарегистрировали свое ООО и стали генеральным директором («вау!»), дело может вообще закончиться «жареным». Не говорите «гоп», пока в вас не «стреляли». Если до сделки вы думаете, что подписание настоящего «крутого договора с синими печатями и классными вензелечками по углам» как-то будет подстегивать вас и ваших коллег, на ваших лбах возгорится звезда вдохновения, и силы не покинут вас даже после пятидесятого чоканья об экран, то вы сильно заблуждаетесь. Все будет как прежде, но лишь до того момента, как о вас не вспомнят кредиторы. А они, в отличие от вас, будут помнить. Потому что вы им теперь должны по определению.

«Фигня, — скажете вы. – Наш проект бесплатен. Мы все – волонтеры (и вообще из параллельного класса). Мы никому ничего не должны!». Не должны? Вот в этом и есть прямая предпосылка таким волонтерским проектам для гарантированного тихого умирания, описанного чуть выше. Потому и работу выполнять свою в срок не должны. И качество обеспечить не должны. И отчитываться тем более не должны (Вопрос: «Не, а ты кто такой?». Ответ: «А ты – кто такой?!» Золотой теленок.). Думаете, это закончится чем-то полезным?

Кто кому должен?

Ну, а что же должны вам коллеги? Что они должны даже в «бесплатных» проектах? Что же такого произошло, как только вы дружно хлопнули по рукам и радостно вскричали: «Поехали!»? Это странно, но, несмотря на бесплатность своих услуг, все теперь должны выполнять предписания вра… распоряжения генерального директора и прочих «генералов», а также указания своего непосредственного начальника. Конечно, если все эти должности существуют, формально или нет. И, конечно, все эти распоряжения должны укладываться в рамки этих самых ваших должностных обязанностей и, естественно, полномочий «приказавшего».

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

Есть такое понятие, как «техасское рукопожатие». Договорились, значит вы обязаны выполнить предмет договора. Существует официальный Контракт или нет, но дело чести довести все до конца, к тому же, как требуется. Но это там, в далекой Америке, а у нас…

Инструктаж пройдем на месте…

И вот вы приступаете к выполнению задачи, тихо-мирно так включаете компьютер, никого не трогаете… «Читай, как нужно делать!», — вопит внезапно подбежавший директор, потрясая какой-то мятой бумагой. – «Выполняй, что предписано!». Настроение падает. Решимость залезть в «Одноклассники» медленно угасает. «Чертов бюрократ! – думаете вы. – Опять эти должностные инструкции…».

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

Инструкции – есть часть системы управления проектом. Поговорим именно о них. Что же такое инструкция (ее разновидность в случае конкретных задач — «стандартная операционная процедура»)? Это набор шагов, необходимых для выполнения той или иной задачи и решения возможных проблем, которые могут возникнуть «по ходу дела». «Вставьте вилку в розетку. Нажмите на кнопку «Power», поверните ручку управления частотой вправо до получения чистого звука. Если звука нет, проверьте уровень громкости с помощью индикатора справа…».

Зачем нужны инструкции? Крамольная для некоторых мысль, но для меня тут яснее некуда – чтобы эффективно и быстро решать поставленные задачи и не изобретать при этом велосипеда. И вообще – вовремя ставить эти самые задачи, без которых ваш проект обречен на… Ну, читайте выше.

Розовые очки реальности

Многие скажут: «Инструкции делают систему неповоротливой, неотзывчивой, неспособной быстро реагировать на изменения и аварийные ситуации». Однако это проблема не конкретной инструкции, а системы управления инструкциями, которая должна позволять дополнять и адаптировать процедуры под существующие реалии. Закон, может, плох, но это закон — куда хуже беззаконие. Но если закон плох, необходима также система изменения его в лучшую сторону. Там же, где законы (инструкции) не меняются, начиная тормозить прогресс и нанося вред общему делу, и возникает ложное мнение вроде «инструкции – в топку, нам лучше без них».

Конечно, иногда, в особо простых, отдельных случаях «можно обойтись и без них». Там, где люди абсолютно верно понимают друг друга, там, где точно знают, что и как делать, там, где не возникает ни конфликтных ситуаций, ни некоего внешнего форс-мажора, не всплывает просто неучтенных обстоятельств, там, где нет точных сроков, ограниченного бюджета и неудобоваримого технического задания. Вы часто такое встречали? Снимите розовые очки! Так бывает очень редко. Ведь это работает, пока… работает, не более того. Но так бывает и в головах создателей очередного «проекта на миллион». А это уже печально. Потому что проблемы будут. Обязательно.

Сезон картошки

Простой пример. Сотруднику ставится единственная задача и, скажем, ее сдача запланирована через неделю. Проходит десять дней. Начальник спохватывается (да и вспомнил-то случайно о работнике – тот просто ему должен денег), звонит: «Как дела? Хоть половину сделал?». Ответ: «Да пока никак, Славка, на картошку ездил, сезон, однако!». «С тебя ведро!» — хихикает «начальник». Приходит заказчик: «Где заказ?». Начальник смущенно, но твердо, потому что не в первый раз: «Делаем. Тестируем. Кофейку? Завтра все вышлем». Как вы думаете, «завтра» будет все готово? Самое смешное, что, возможно, и «будет». Потому как изначально не разобрались, что цена всей этой задаче от силы 4 часа, но при этом никакого тестирования проводить не станут – «А зачем? Работает же вроде!».

Немного теории

В данном случае необходимость есть как минимум в нескольких инструкциях, точнее, «стандартных операционных процедурах» (СОП, англоязычный вариант — SOP).

1. Процедура по инициированию рассмотрения реализации задачи. Идей может быть много. Слишком много. Безумцев хватает. И на их простое рассмотрение может уходить просто уйма времени — вашего бесценного времени. В этом случае необходимо задаться следующими вопросами, которые и описаны в данной инструкции. Что именно нужно сделать? Следует ли это делать в принципе? Как это описать? Кто будет рассматривать ее как технический специалист? Кто будет принимать решение о попытке рассмотрения данной задачи вообще? Это в принципе реализуемо? Сейчас именно тот момент, когда проекту чего-то не хватает? И где это должно быть описано, чтобы все, кому надо прочитали, а те, кому нельзя смотреть, не подсмотрели? Какими словами нужно это описать? Это просто сверкнувшая идея или следствие другого, уже существующего задания? Какие материалы приложить? Какие доводы привести? Нужно ли чье-то авторитетное мнение как аргумент?

Все эти вещи следует подробно описать в инструкции как пошаговое руководство, чтобы уже самое первоначальное обсуждение задачи с начальством или специалистом не вылилось в недоуменно-раздраженное: «А что это ваще? Ничего не понял… Давай-ка займемся подобной фигней через месяц-другой…».

2. Процедура определения ресурсов для реализации задачи определяет инструкции оценки следующих ресурсов:

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

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

4. Процедура описания задания для его реализации. Когда принято решение о том, что задание реализовывать стоит, его нужно описать уже в формате для конкретных исполнителей. Вариант «Нужно нарисовать дерево» очень плох. Непонятно – какое именно «дерево», где оно будет выводиться, для чего и, соответственно, в каком стиле, какого размера, каковы выходные форматы файлов и пр. В противном случае художнику придется перерисовывать «березу в дуб», а потом обратно и, наверняка, не один раз – а это и есть перерасход времени, сил, возможно, финансов и нарастающее общее напряжение и конфликтность. В случае программистов все еще «запущеннее». Им нужно давать предельно разжеванные задания, четко определяющие «где лево, а где право». Написать им «Нужно анимировать гномика» значит нарваться в лучшем случае на гомерический хохот и коренную переделку вами всего задания. В худшем это будет пошло или не будет работать вообще, но в итоге снова те же самые проваленные сроки и финансы. Таким образом, в процедуре (их должен быть целый пакет для однотипных заданий или должностей) должно быть весьма четко описано: как и что описывать для разработчика, чтобы ваше желаемое однозначно совпало с его реализуемым.

5. Процедура передачи задания исполнителю. Мало написать задание и с усталым, но удовлетворенным видом откинуться на спинку престарелого, но кожаного кресла, оставшегося от прежнего владельца офиса. Как это задание получит разработчик? Он получит автоматическое оповещение на почту или ему нужно звонить в коммунальную квартиру и долго кричать в трубку, вызывая его дух среди 37 постояльцев? А вы уверены, что он заглядывает на почту каждые 15 минут? Что он вообще возьмется за его исполнение (а то ведь у картошки сезон)? Что когда он возьмется, вы тут же узнаете об этом, потому что хотели бы проконтролировать самое начало и кое-что изменить уже сейчас? Данная процедура должна подробно описывать все эти нюансы – кто, кому, когда и как передает документы и «дает отмашку». Вообще должен быть так называемый принцип неотрекаемости – если задание заведено в некоей системе (например, Project Management вроде Podio, Do.com или Basecamp), то получатель гарантированно его получит на свой email, телефон и тому подобное, и после этого он в принципе не вправе по-детски лепетать, что «никакого оповещения не было, наверное, сервер глюканул, а я сидел и ждал». Но даже при наличии этого принципа в данной ситуации лучше предусмотреть что-то типа отзыва исполнителя: «Задание получено, я все понял». Для вашего же спокойствия.

6. Процедура контроля выполнения задания. Хорошо, задание получено. И вроде даже начато его исполнение. Что дальше? Задача может быть очень важной, крайне. А у исполнителя «так много родственников по стране, и они все такие болезненные («Берегись автомобиля»)… Всегда необходим контроль за ходом работ. О, нет, не стоит звонить разработчику каждые полчаса и истерическим голосом спрашивать, сколько пикселей он уже покрасил или строк кода написал! Это раздражает просто жутко. Однако информацию в виде процентов исполнения, понятно, что примерно, он обязан предоставлять – в той же системе Project Management., скажем раз в день или раз в два дня, неважно – но, опять же, по согласованию с данной инструкцией. Если задание большое, возможны промежуточные отчеты по ходу исполнения и возникающим проблемам — либо привязанные к датам, либо к этапам работ. Подобные вещи и описываются в данном протоколе – что, когда, сколько и как.

7. Процедура выполнения задания разработчиком. Эта процедура – суть описания специфических действий, зависящих от собственно выполняемой задачи. Что делать разработчику? Как делать? Какие проблемы могут быть и что делать для их решения? Тут может быть как две строки, так и 200 страниц убористого текста, универсальных решений нет… Но именно это часто уберегает время, нервы и силы исполнителя.

8. Процедура сдачи задания. Итак, работа сделана. Теперь ее надо сдать. Процедура описывает как передается результаты задачи, кому, в каком виде, как происходит оповещение заинтересованных лиц.

9. Процедура тестирования задания. Получение результатов задания еще не означает окончание истории. Необходимо проверить – то ли сделано, с надлежащим ли качеством и так далее. Фактически, это этап тестирования (огромная отдельная тема для обсуждения). Очень важный этап, поэтому процедуры тестирования – неотъемлемый атрибут качественного продукта. К сожалению, слишком часто это игнорируется разработчиками. Инструкция тестирования пишется для конкретного задания, в зависимости от ее специфики и максимально подробно. В ней перечисляются все условия, при которых может функционировать «результат задачи», либо то, «как это должно выглядеть», если это рисунок (то есть соответствие техзаданию). Плохо написанный сценарий тестирования является причиной ошибок и багов в конечном продукте.

10. Процедура принятия задания. Само по себе тестирование – это просто тестирование. Формально работа по задаче еще не принята. Теперь необходимо описать шаги по «включению» задачи как формально (ставится «плюсик» о выполнении, а сдельному платному работнику еще и начисляется заработок), так и практически – например, если это рисунок, то что с ним делается дальше, каким заинтересованным лицам становится об этом известно, чтобы они могли это использовать в своих заданиях, кому он передается «физически», где хранится, как хранится и пр.

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

Впечатляет? Но это только основные, общие процедуры-инструкции по ведению «всего-навсего» задания! Для отдельных, специфических задач обычно пишутся свои СОПы. Но именно эти шаги помогают выполнить все намеченные задачи, делать только то, что требуется – в срок, без превышения финансовых или материальных ресурсов и, в конечном итоге, закончить проект, а не жалеть потом о том, что вообще связались с ведением таких дел, пряча глаза от заказчика или кредитора.

Бюрократия

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