Топ 3 моих «любимых» цитат, преподнесенных как совет в процессе обсуждения развития сотрудников.

№3 – Мотивация зарплатой.

Будет хорошо работать – замотивируем повышением зарплаты!

Зарплата, это не мотивирующий, это сдерживающий или, как это грамотно обозначено, «гигиенический» фактор (Herzberg, F., Mausner, В., and Snyderman B. The Motivation to Work. N.Y: John Wiley, 1959), предотвращающий желания сотрудника к смене рабочего места.

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

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

№2 – Мотивация вызовом «на ковёр» (это моя любимая часть).

Вызови человека, укажи на его недостатки – замотивируй его этим!

И что? И как от «кнута» может человек работать лучше и хуже? Сотрудник, возможно, поймет, что он был где-то неправ, но от этого ничто в его организме не заставит его сделать схожую работу качественнее и (не или!) быстрее. Люди – существа меркантильные и самолюбивые от природы. Значит, если, по достижению улучшения качественные показателей того, что делает человек, не предоставить организму или уму нечто (побуждающий мотив), что служило бы поддержкой или ублажением первого или второго «чертика» – то никакое действо не будет совершено, чтобы на это направлять усилия.

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

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

Но, пожалуйста, помните про №1.

№1 – Мотивация нереалистичными сравнениями.

- Это надо делать так, потому, что так надо!

- А что мне с этого?

- Ну просто так будет лучше и ты будешь лучше!

Для кого лучше? Для Василия Пупкина из села Кукуево**? Для детей Африки? А что до этого дела персоне, которой вы все это говорите? Да и лучше по сравнению с чем? А почему весь этот парадокс мироздания должен волновать вашего собеседника? И т. д.

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

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

* – Мотивировать человека при разборе его недостатков – нонсенс, но такое происходит повсеместно, поэтому и попадает в топ №3 ошибок руководства.

** – Если на планете Земля есть село Кукуево и там живет г-н Василий Пупкин, то я заблаговременно прошу у него прощения за использование сего имени в тексте статьи.

Вы когда-нибудь задумывались, что есть рабочий день у программистов, профессия которых, IMHO, тесно сопряжена с творчеством и наукой? Сколько часов в день, скажем, человек действительно созидает нечто осязаемое, а сколько времени обдумывает идею или изучает новые техники? А ещё вопрос – сколько этот человек тратит в день на себя, а именно, «кофейные» сплетни,  всякие youtube, facebook и смежное, если есть выход в интернет?

Формула.

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

Tcreative = 8h*Kmaturity – Tego – Tnoise,

Где:

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

Kmaturity – это коэффициент опыта программиста в условиях этого проекта, или задач. Вариации от самых слабых разрабочиков (0.5+), до матерых профессионалов  (1.0+)

Tego - это время, которое тратит программист на себя.

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

Делаем выводы.

Программистам, посвящается -

• Отвечая на вопрос «сколько времени тебе требуется на…», учитывать такую формулу, и аргументированно отстаивать грамотные сроки перед своими начальниками.
• Обращаясь к сознательным, которые расширяют рабочий день в офисе чтобы успеть и >Tcreative сделать и Tego уделить. Необходимо сокращать время Tego до минимума, не позволяя себе пересиживать в офисе больше 8-9h в день, если того не требует ситуация, но о выгорании ресурсов человека – в отдельной статье.
• Обращаясь к тем, кто не верит в формулу – мы то все видим

Менеджерам, посвящается -

• Принимайте во внимание то, какие люди с вами работают – «хирурги» или «ассистенты»  (см (1975). The Mythical Man-Month. Addison-Wesley. ISBN0-201-00650-2.) и учитывайте среднее значение Kmaturity.
• Учитывайте, что чем больше команда, тем больше «шума» в коллективе и тем, собственно, меньше работает конкретный человек. Для классических методик я советую учитывать 10% шум в день, в agile проектах это время равняется 3-5%
• При постановке задач и утверждении сроков поставки, учтите эго команды и также включите доп время в длительность проекта. Минимальное время на эго – 20% в день!
• Влиять сторонне можно и нужно на сокращение Tnoise до минимума (убрать ненужные совещания, разбить команду на подгруппы) и увеличение Kmaturity до максимума (тренинги, парное программирование).
• Увы и ах, но влиять на Tego невозможно. И тут остается только следить или за синдромом пересиживания или искоренять лодырей из проектов.

Соответственно,

• Самое главное, прописанное в миллионах книг, статей, и проверенное мною не раз, правило утрвеждает, что люди – это нелинейный механизм, и нельзя планировать проектные сроки оперируя терминами «человеко- час/месяц/год» или, проще говоря, - люди не работают по 8 часов в день.
• Длительность проекта или возможности итерации в agile средах, зависит от реального трудодня человека, которое равнозначно, в среднем, 6-7 часам или 80% коэффициенту для подсчёта team velocity в спринтах.

Пользуйтесь.

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

Господа, It-шники, которые используют хотя бы 3 слова из цитаты выше. Это обращение направлено именно к Вам (включая Вашего покорного слугу в первых рядах).

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

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

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

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

* Runglish – term for describing the Russian-English pidgin language / Wikipedia.

** Bug – an error in a computer program or system / Oxford Dictionary.

1. Оценку базировать на исторических сведениях (схожие работы, схожий вид деятельности) и/или экспертном мнении (ведущие и ключевые персоны с большим опытом в подобных проектах)
2. Учитывать ВСЕ возможные риски и оценить как варианты их устранения (Risk Mitigation), так и затраты на последствия (Risk Contingency)
3. Четко и, по возможности, детально понимать условия и предположения (Assumptions) на которых вы базируете свою оценку.

К полученной стоимости добавляем расходы на инфраструктуру, непредвиденные обстоятельства (Contingency) – и вот вырисовывается стоимость работ.

Но это идеальный мир, утопия.
А мы заберемся в дебри сложностей, поговорим  о наболевшем. А именно, что делать если…

Если отсутствуют четкие требования к проектным задачам (90% случай).

Первое правило джедая. Не написанное требование – не требование вовсе. Однако, добиться от заказчиков оформления детальных задач на бумаге – это начала тоста «Ну, за фантастику!». Это было и будет всегда, а именно, выяснение стоимости до того, как заказчик начинает представлять себе задачу. Так что без паники – это все проходили. Что надо делать:

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

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

• Если нет возможности обсудить требования, или границы проекта все же недостаточно ясны, необходимо оценивать проект на предпосылках, каждый из которых также оценить в критериях «если неверно, то -».
• В дополнение, следует оценить достоверность получаемой суммы в % (Confidence Level)  и оценить разницу с единицей  как «фактор неучтённых требований». Когда заказчики видят сумму денег, которую они могут потратить на ничто, они начинают понимать цену технических заданий.
  Рамки возможных неучтённых требований: 
  • 5% – я знаю всё (да да, все равно 5% надо);
  • 6-10% – многое понятно, но есть маленькие пробелы;
  • 11-20% – существуют значительные пробелы в описании задач;
  • 21-30% – критические моменты проекта не ясны;
  • >31% – вы глядите на чистый лист бумаги.

Если вы делаете проект впервые.

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

Если вы работаете на себя, или это стартап, то выходом является использование достижения нашей эры,  а именно,  - массовое и широкое распространение информации.  Исторических баз знаний о проектах в Интернете полным-полно, однако, верить нужно лишь усреднённому значению. А лучше использовать платные услуги (если проект действительно сложен), благо таких услуг также предостаточно. Я доверял бы исключительно freelance инженерам, с высоким рейтингом, которые имеют в portfolio схожие проекты, но не кидался бы на вывески «outsource estimation companies» (ну если только вам не порекомендовали их надежные люди).

Т.е. и там и тут вы, так или иначе, обязаны выполнить или делегировать выполнение условия №1 из трёх «китов» процесса оценки трудозатрат.

Если вы делаете проект как подрядчики, и вам говорят ваши сроки.

Не стоит браться за проект, не проанализировав и не подтвердив его трудозатраты. Это аксиома.  Если вы наработаете в данном процессе некоторый уровень автоматизма, это не займёт много времени.  Более того, выполнив три условия оценки работ, вы сможете отстоять своё мнение, базируясь на фактах.

А если не верят или упирают на неверности решений… То решайте, не рискуете ли вы всем. Я не могу здесь настаивать, все же условия бывают разные, но я бы не стал браться за работу.

Кроме того, какой же вы менеджер, если не можете отстоять мнение

Если это pre-sale и у вас есть 10 секунд на оценку.

Тут все просто. Или вы хотя бы на 70% уверены (у вас был схожий проект или вы подготовились к совещанию\звонку), или вы говорите встречный вопрос и, вспоминая игру о «захвате территорий» узнаете о проекте больше и можете склонить стороны к рассмотрению вопроса в выделенное время. Но врать или сочинять нельзя!

Вот такие вот правила – вот такие вот игры.

Пользуйтесь.

Те, кто родился на просторах СССР или его пост-площадях,  должны помнить из детства такой мультик, где ёжик и медвежонок постоянно считали ромашки.  Кажется,  »Трям, здравствуйте!» назывался.  Сам мультик  - не суть, а вот тему ромашек мы и затронем сегодня.

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

Моя первая «ромашка»  - классический процесс разработки компонента любого программного обеспечения (далее – ПО) с точки зрения постановки задач для каждого разработчика.

Как видно, процесс начинается с разбора технических требований (Elaborate), затем идёт фаза технического дизайна и создания набросков наиболее критичных частей системы (Design, Prototype). Далее идёт непосредственно фаза кодирования и тестирования в изоляции (Implement & Unit Test). Затем – фаза тестирования под нагрузкой и анализ контекста компонента (Profile), которая завершается возможным обновлением кода для корректировки показателей производительности и масштабируемости (Refactor). Завершающими циклами идёт фаза системного тестирования (Test) и написание документации (Document).

А вот ещё её сестра – гибкая и модная «ромашка-XP», которая описывает процесс разработки ПО в «гибких командах» (Agile/XP) с применением так называемого Test Driven Development

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

А далее идёт магия: пишутся тесты над интерфейсами будущих компонентов, которые изначально должны показывать ошибку, а потом создается код, который при «прогоне» с тестами выдает положительный результат. Как говорит теория и как доказано на практике – стабильность кода в данном подходе выше, чем при классическом процессе.

Далее – цикл системного тестирования (Test) и написание документации (Document). И завершает все фаза анализа и обновления кода, которой в этом процессе отводится значительно большее время для устранения риска как указано выше.

Все хорошо, но это – теория и идеал! А в реальности все выглядит так, как показано на моей «Post Nuclear ромашке» (да простит меня природа за это убожество):

М-да, страшненько выглядит. И так же потом и работает… Кодирования много, тестов и документации – мало. Фаза дизайна может присутствовать, но она отделена от разбора технических требований и опускает такой важный компонент процесса, как прототипирование.

А результаты –

1. Риск неверной трактовки технического требования или невозможность достижение результатов из-за технических проблем – переделка.
2. Возможные проблемы с производительностью и дальнейшим расширением.
3. Среднее или плохое качество программного продукта как внутри компонентов, так и в системе целиком.
4. Дорогостоящий и трудоёмкий процесс поддержки данных систем.

Провал…

Почему так происходит. Причина в сверх-широком понимании классики описания процесса –  как Design, Code, Test, Repeat – которое закладывается ещё с технических ВУЗов (беру срез выпускников из Беларуси на 2000-2010 гг., чтобы никого не обидеть). Вот какая «ромашка-пропеллер» в голове у молодых специалистов.

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

Суммируя, хочется ещё раз подчеркнуть, что для успешного создания ПО каждый из разработчиков (помимо их проектных лидеров) должен знать полный цикл процесса

elaborate -> design -> prototype -> implement & unit test -> profile & refactor -> test -> document

Или (если вы опытный управленец):

elaborate & design -> unit test & implement -> test & document -> profile & refactor

Используйте.

- «Just a drink, a Martini, shaken not stirred.»  J.Bond Dr. No (1958)

Взболтать

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

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

Таким был я. Думал, что я – творческий человек,  поэтому, любые ограничения и планы - это не для меня; составление списков – это  бесовство и признак старости, а любая форма введения временных рамок – попросту нереальная задача.

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

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

Из личного, я могу привести пример создания макетов для одного приложения, которые я делал используя технику «помидоров».  через 4-5 итераций я мог с уверенностью прогнозировать результативность каждого из «спринтов» как 1-2-3 готовых макета. Обучение технологий и/или выполение тестовых заданий – ещё один пример из личного опыта.

Главная задача – верить в ритм. И не отчаиваться если первые 2/5/20 фокусировок будут провальными. Будет ведь 3/10 и 50 ещё.

Обладая списком задач мы позволяем мозг отдохнуть от постоянного контроля приоритетов и важности. Записывая успехи и неудачи мы учимся, а, значит, предотвращаем схожие ошибки от повторения. Записывайте, помечайте приоритеты, пользуйтесь инструментарием, например Remember the Milk (http://www.rememberthemilk.com/) для организации вашего времени.

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

Позволяя себе отдыхать мы подготавливаем организм и сознания для последующего фокуса на работу. Отдых важен. Это единственное правило которое, как говорят - the must.

Три простых правила – взболтайте как угодно. Если ищете подтверждения теории в известных источниках, то советую начать с книг Глеба Архангельского или задуматься над легковесной, простой и понятной, а значит особенно удачной трактовкой ритма от Francesco Cirillo - The Pomodoro Technique™ .

Не смешивать

При использовании правил важно понимать и различать понятия фокусирования задачи и полной изоляции. Если вы – начальник и работаете с людьми, то я не советую уходить в себя и отрекаться от внешнего мира  при выполнении задач. Вы можете пропустить важный звонок или не успеть отреагировать на приоритетную задачу.  Простой диалог «что случилось?.. Может ли подождать 5/10/20 минут, пожалуйста?» спасёт от многих ситуаций. Люди - нелинейные и не подчиняются ни одному процессу или технике.  Помните об этом и не позволяйте процессу работать выше вас. Более того, техника ритмичной работы не упраздняет коммуникацию на любом уровне если она ведется по задаче, над которой вы работаете.

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

Итого

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

Используйте.

1. выгода для компании: краткосрочный план и/или стратегическое развитие

2. выгода для клиента – заказчик должен видеть ЕГО прибыль от проекта, за который он платит.

3. общие сроки и прогресс: временные и финансовые.

4. возможность выполнять запланированные активности – надежность инфраструктуры.

5. риски и способы их устранить.

-

6. мотивацию подчинённых координаторов проектов, чтобы решать 1,000,000.00 остальных записей в чеклистах: планирование, координирование, управление изменениями, тим билдинги, сроки, поставки, ресурсы и т.д.

Сталкивались ли вы с ситуацией когда представители «верхушки рабочего класса», в моём случае – это ведущие/ключевые программисты, при определённых условиях, попадают на руководящие роли? Если ответ да, то буду очень удивлён вашей кармой и везением, если вам сразу же понравились достижения и успехи прежнего top tech performer‘а, а ныне совсем неопытного лидера, – ибо если это так, то вам достался искусный мастер Йода, тайно прятавший талант организатора. Но я не думаю, что бывает безстрессовый переход человека от исполнительной к руководящей роли. Безстрессовой как для человека, так и для его руководителей.

Я работаю в компании где «линия партии» всегда была и будет направлена не на качество, а на количество поставок. Именно в этой компании я когда-то впервые услышал описание человека как «ресурс». И именно благодаря этой политике все проектные лидеры, с которыми я работал (да и сам тоже), были выдернуты по принципу «Ну это же супер разработчик, значит и с командой будет «жечь». Но да не суть, да и не жалоба это. Скорее стечение обстоятельств, которое вынудило меня сначала обучиться самому, а потом и обучать других людей переживать этот самый процесс внутреннего «шторма», при попадании, как говорится, «из огня да в полымя». На самом то деле, эти выходцы из народа действительно лучшие люди: лучше понимают техническую задачу, лучше оценивают риски, четче понимают внутренние процессы и т.д. Вот только надо переломать некоторые (большинство) из заблуждений, приведенные внизу, дабы упростить им (и вам) первые 3-5 месяцев проекторуления:

1. Почти все – дибИлы, только {имя} хорош(ая)!

Верите, что не бывает плохих людей, но бывает неправильный подход? Не верите? А стоит. И этому надо учить лидера (и вас, если не верите). Сошлитесь на теорию X & Y, чтобы занять пытливый мозг «технаря» логическим подтверждением этой аксиомы. И напомните, что он тоже не был гением лет 5 назад

2. Я лучше сам всё сделаю! Они же совсем не работают!

Вот уж нет. Лидер\Менеджер должен управлять проектом, координировать части, но не стремиться сделать все сам – так времени не будет, ни на хороший код, ни на фокусировку на проблемах\рисках проекта. Хороший менеджер должен уметь разделять и властвовать. Делегирование, делегирование и делегирование. Научите его делать это правильно.

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

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

4. Меня задергали. Я не успеваю ничего сделать.

Научите говорить его «Занят», а также умению планировать «коридоры общения» с командой (и с руководством!) заблаговременно и грамотно. Проверьте что лидер понял что между встречами или задачами создается некий «воздух», как раз для обсуждений рутины с подчинёнными (и с начальством!). Объясните ему, что ответ «не могу сейчас, занят очень», не означает, что он будет выглядеть слабым в глазах его подчинённого\начальства (типичный страх). Это лишь докажет его команде, что лидер работает не меньше других и понимает насколько важно иногда сконцентрироваться на деле.

5. Я думал, что справлюсь с проблемой сам…

Как и в случае выше, типичный страх человека, оказаться слабым в глазах другого человека (начальства). Это очень сильно проявляется в «выходцах из народа», так как на протяжении лет они были корифеями знаний и действительно умели решать проблемы сами. Технические проблемы. Но это не работает в управлении. Тут все наоборот – чем раньше замечен сбой\отклонение от правил – тем быстрее надо оповещать свое начальство – тем лучше показатель умения управлять проблемами и рисками проектов. NB! Стоит все же заметить, что это правило не абсолютно и объяснить как категоризировать отклонения на эскалируемые (доносимые начальству) и скрываемые.

Ну и на последок – венец проблем

Устал, я. Как все сложно. Подчинённые не слушаются. Проект не идёт. Сроки сорваны. Лучше бы сидел и кодировал.

Спокойствие, только спокойствие. (Карлсон, который живёт на крыше). При соблюдении пяти правил расписанных выше ваш новоиспеченный проектный лидер скоро забудет эти слова.

Итого, формула нашего лидера – это правильный подход к людям (1), планирование(4), делегирование(2), контроль(3) и управление проблемами(5).

Используйте.

Которые я познал и которые стараюсь применять на практике.

1.

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

2.

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

Используйте.

При планировании работ, неважно это waterfall или agile пользуйтесь правилом 1/1/1. А именно:

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

Просто задать, просто проверить.

Если задание не сделано в срок по внешним причинам¹, то необходимо перенести работу или целиком, или, разбив задачу на составниые рабочие(!) части,  выносим проблемную  на «подкорректированную»² неделю данного человека.

1. Внешние причины – причины выходящие за границы ответственности исполнимого

2. т.е. ту неделю, когда все внешние причины разрешены.

При agile development вести учёт переносов и причин, а также увеличивать оценку трудозатрат схожих задач при выявлленых похожих рисках.