Заметка Об Инструкции (Без Претензий На Мировое Господство)



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

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

Потому что экраны не терпят звона стаканов.

Итак, вы думаете, что это ерунда и пустая трата времени.

Мол, управление проектами — это бюрократия и удел «старых персов или западных фарисеев»? Тогда будьте осторожны.

Бизнес не сложится, а вы прогорите.

В лучшем случае ваш «проект» тихо умрет, и вы даже не поймете, в какой момент это произошло.

Сначала незаметно исчезнет один человек, даже не сдав последнее задание, затем второй.

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

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

И все начнется заново.

Только с тем же результатом.

Могло быть и хуже.

Если вы заняли деньги у друзей, да еще с темным прошлым, или получили контракт от дистрибьютора или хотя бы простого клиента, или взяли кредит в банке, зарегистрировали свое ООО и стали генеральным директором( "Ух ты!" ), все может даже оказаться «поджаренным».

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

Все будет как раньше , но только до тех пор, пока о вас не вспомнят кредиторы.

И они, в отличие от вас, будут помнить .

Потому что теперь вы им должны по определению.

«Чушь», — скажете вы.

- Наш проект бесплатно .

Мы все волонтеры (и вообще из параллельного класса).

Мы никому ничего не должны!» Не должна? Это прямая предпосылка подобных волонтерских проектов для гарантированного тихого умирания, описанного чуть выше.

Поэтому им не следует выполнять свою работу вовремя.

И качество не должно быть гарантировано.

И им даже отчитываться не надо (Вопрос: «Нет, а вы ктоЭ» Ответ: «А вы кто?!» Золотой теленок.

).

Как вы думаете, закончится ли это чем-то полезным?



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

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

Если тебе дают задание, ты берешь его на себя обязательство выполнить его.

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

Есть такое понятие, как «Техасское рукопожатие».

Мы договорились, а значит, вы обязаны выполнить предмет договора.

Независимо от того, есть официальный Контракт или нет, довести все до конца, как того требует, дело чести.

Но это там, в далекой Америке, и здесь.



Мы дадим вам инструкции на месте.

И вот вы начинаете выполнять задание, тихо и мирно включаете компьютер, никому не мешая.

«Читай, как это сделать!», - вдруг подбежал директор, крича, тряся какую-то скомканную бумагу.

— «Делай, что предписано!» Настроение падает. Решимость попасть в «Одноклассники» постепенно угасает. «Проклятый бюрократ! - Вы думаете.

«Опять эти должностные инструкции…» Но что написано в этих самых должностных инструкциях? Конечно же, инструкции, которым необходимо следовать «на месте».

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

Это бюрократия? Нет, не сейчас.

Инструкция - есть часть системы управления проектами .

Давайте поговорим о них.

Что такое инструкция (ее вариант в случае конкретных задач — «стандартная рабочая процедура»)? Этот набор шагов необходимо для выполнения той или иной задачи и решения возможных проблем, которые могут возникнуть на этом пути.

«Вставьте вилку в розетку.

Нажмите кнопку «Питание», поворачивайте ручку регулировки частоты вправо до тех пор, пока не получите чистый звук.

Если звука нет, проверьте уровень громкости по индикатору справа.

".

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

Ну читайте выше.



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

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

Закон может быть и плох, но это закон – беззаконие гораздо хуже.

Но если закон плохой, необходима и система его изменения к лучшему.

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

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

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

Вы часто это видели? Снимите розовые очки! Это бывает очень редко.

Ведь оно работает пока.

работает, не более того.

Но это происходит и в головах создателей очередного «проекта на миллион».

И это уже печально.

Потому что будут проблемы.

Обязательно.



Картофельный сезон
Простой пример.

Сотруднику дается одно задание и, скажем, его сдача запланирована через неделю.

Проходит десять дней.

Начальник приходит в себя (и случайно вспомнил о сотруднике — тот просто ему денег должен), звонит: «Как дела? Вы сделали хотя бы половину? Ответ: «Пока нет, Слава, я пошел за картошкой, еще сезон!» «У тебя есть ведро!» - хихикает «босс».

Приходит покупатель: «Где заказЭ» Начальник смущается, но твердо, потому что это уже не первый раз: «Мы так делаем.

Мы тестируем.

Кофе? Завтра все отправим».

Думаете, «завтра» все будет готово? Самое смешное, что, возможно, «будет».

Потому что изначально не понимали, что стоимость всей этой задачи составит максимум 4 часа, но при этом никакого тестирования проводить не будут - «Почему? Вроде работает!»

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

1. Процедура начало обзора реализации задания.

Идей может быть много.

Слишком много.

Есть много сумасшедших.

И простое их рассмотрение может занять много времени — вашего драгоценного времени.

В этом случае вам необходимо задать следующие вопросы, которые описаны в данном руководстве.

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

Давайте разберемся с такой фигней через месяц-два.

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

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

    ),

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

3. Процедура принятие решения о необходимости реализации задания.

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

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

Вариант «Нужно нарисовать дерево» очень плох.

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

«береза в дуб», а потом обратно, наверное, не один раз – а это перерасход времени, сил, возможно, финансов и возрастание общей напряженности и конфликтности.

В случае с программистами все еще более запущено.

Им нужно дать предельно подробные задания, четко определяющие, «где лево, а где право».

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

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

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

5. Процедура передача задачи подрядчику .

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

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

В общем, должна быть так называемая принцип неотречения — если задача вводится в определенную систему (например, Project Management типа Podio, Do.com или Basecamp), то получатель гарантированно получает ее на свою электронную почту, телефон и т. д., а после этого он в принципе , не имеет права лепетать как ребенок, что «Никакого уведомления не было, наверное сервер глючил, а я сидел и ждал».

Но даже при таком принципе в данной ситуации лучше предоставить что-то вроде обратной связи от исполнителя: «Задание получено, я все понял».

Для собственного спокойствия.

6. Процедура контроль исполнения задания.

Хорошо, задание получено.

И кажется, что его исполнение даже началось.

Что дальше? Задача может быть очень важной, чрезвычайно.

А у исполнителя «столько родственников по стране, и они все такие больные («Берегись машины»)… Всегда необходимо следить за ходом работы.

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

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

Подобные вещи описаны в этом протоколе – что, когда, сколько и как.

7. Процедура выполнение задачи разработчиком .

Данная процедура является сутью описания конкретных действий, которые зависят от конкретной выполняемой задачи.

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

8. Процедура сдаю задание .

Итак, работа сделана.

Теперь его нужно сдать.

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

9. Процедура тестирование задач .

Получение результатов выполнения задания не означает конец истории.

Необходимо проверить, сделано ли это, должного качества и так далее.

По сути, это этап тестирования (огромная отдельная тема для обсуждения).

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

К сожалению, слишком часто это игнорируется разработчиками.

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

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

Плохо написанный тестовый сценарий приводит к ошибкам и ошибкам в конечном продукте.

10. Процедура принятие задания .

Тестирование само по себе является всего лишь тестированием.

Официально работа над заданием пока не принята.

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

Ведь в серьезных проектах история задачи на этом не заканчивается.

Часто за ним необходимо продолжать наблюдение – по той или иной причине.

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

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

Принять во внимание эти вещи может быть сложно.

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

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



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

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

Теги: #Управление проектами #СОП #инструкции #болезненно #бюрократия #Разработка мобильных приложений #Разработка игр

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.