Взболтать, но не смешивать.

 - «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).

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

<!–[if gte mso 9]> Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 <![endif]–><!–[if gte mso 9]> <![endif]–> <!–[endif]–>Я работаю в компании где «линия партии» всегда была и будет направлена не на качество, а на количество поставок. Именно в этой компании я когда-то впервые услышал описание человека как «ресурс». И именно благодаря этой политике все проектные лидеры, с которыми я работал (да и сам тоже), были выдернуты по принципу «Ну это же супер разработчик, значит и с командой будет «жечь». Но да не суть, да и не жалоба это. Скорее стечение обстоятельств, которое вынудило меня сначала обучиться самому, а потом и обучать других людей переживать этот самый процесс внутреннего «шторма», при попадании, как говорится, «из огня да в полымя». На самом то деле, эти выходцы из народа действительно лучшие люди: лучше понимают техническую задачу, лучше оценивают риски, четче понимают что внутренние процессы и т.д. Вот только надо переломать некоторые (большинство) из заблуждений, приведенные внизу, дабы упростить им (и вам) первые 3-5 месяцев проекторуления:

Простые истины мотивации человека.

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

1.

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

2.

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

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

1+1+1

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

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

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

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

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

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

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

Конфликты в условиях кризиса.

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

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

Примерами ситуаций, возникающих на фоне кризиса, и приводящих к конфликтам можно отнести:

1. прекращение проектов или сделок, когда начинают уходить клиенты, жалуясь на недостаточное количество средств для продолжения сделок;
2. как следствие, сокращение штата компании или\и снижение заработных плат или иные формы экономии;
3. как следствие, демотивация и деморализация персонала;
4. как следствие – стрессы, сcоры, обиды и разочарования.

Рассмотрим принципы снижения количества или разрешений конфликтов.
Борьба со слухами.

Многие трудовые конфликты, связанные с вопросами условий, содержания, организации труда и его оплаты, связаны с атмосферой, созданной в организации.

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

1. стратегию компании по «выживанию» в условиях кризиса; желательно указать ссылки на смежнгые компании дабы пресечь поползновения сотрудников поиграть в Ш.Холмсов и  разузнать «а чё там у Васьки твориться, можон у него лучше»;
2. ожидаемые трудности\риски и методы борьбы с ними;
3. изменения в условия труда, их причины и сроки;

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

Снижение зарплат.

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

1. определить коэффициент прибыли, который способен удержать компанию «на плаву»;
2. определить методы экономии расходов, не связанных с выплатой зарплат: возможно вы оплачиваете банный комплекс для всех сотрудников ежемесячно или вы заказываете в офисы «золотой» кофе;
3. определить ключевых сотрудников на которых не будет влиять решения принятые ниже, эдакий «SWAT». Подчеркиваю, что должность при определении ваших «элитных» ресурсов тут не имеет почти никакого значения.
4. определить возможность сохранения зарплат критической массе «пчёл-трудяг» путём увольнения планктона – сотрудников показывающим вялотекущий прогресс и отсутствие самомотивации. Это кризис – тут нельзя расслабиться!
5. принять решение о снижении зарплат. важное правило устранения конфликтов: если снижать – то всем из одного «горизонта» (отдел, регион, должность и т.д.). Оставляю это правило в категории сюрреализм и фантастика, так как в действительности это случается редко. Se la Vi.

Увольнение персонала.

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

• Максимально четко формулировать причины сокращения штата.  Формулировать нужно всем в отделе! Это позволит избежать конфликтов понимания ситуации различными слоями сотрудников;
• Избегать личностного анализа увольняемых людей и применять широко известные техники определения факторов для увольнений для избежания межличностных разногласий – пусть «говорят» только цифры;
• Мотивировать как оставшуюся часть персонала так и увольняемых максимально допустимыми «увольнительными» положенными по трудовому законодательству. Не жалейте денег – это благотворно скажется в сохранении «лица» компании.

Напоследок…

Харизматики в условиях кризиса.

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

Как вывод из вышесказанного, могу суммировать все в следующей фразе.

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

Удачи.

Why so serious?

Начнём с истока всего:

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

- А потому, что именно этой фразой закончился один из первых (очень неудачных) проектов ведомых мной. – Ответил ему я.

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

Бардак и разгром. Ну как курятник!..

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

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

Я дважды собирался начать писать статьи. Как видно, прошёл год с момента публикации последнего очерка. Тогда я ещё думал писать на английском, благо имею такую возможность, но зачем?.. Если и будут читать – то пользователи ru-/by- нета. А если уже стану читаем вовне – то, уверен, что перевод статей не займет большого времени, нежели чем их созидание.

Все это в прошлом. Теперь моя цель не массовость (ну т.е. это вторично), а реализация мыслей в письме. И, дай Бог, когда-нибудь они будут правильными и полезными. А главное, веселыми!

Chicken Runaway! Epilogue.

Gosh!.. Long time passed by since I’ve posed last (first) comment. Hopefully I’ve got some time to re to “Chicken Run” syndrome case as I’ve promised. Alight, here is the follow up on the case.

Sam’s mistakes:

1. Thinking about human treats and moods – this is the anchor point of team success.
   There is no way of moving forwards when key team mates have no confidence and respect to each other. To mitigate this it’s strongly recommended to:
   • Not to assign conflicting peers on same task;
   • If that’s impossible – it’s a task to establish very formal communication line between them (with involvement of “other” peers), plus identifying details of their touch points
2. Verbal requirements – wacky deal! It’s nothing unless written on paper and agreed among all. Requirements must be shared in project in written form. Details are applicable and important too, however this might be done in sevaral ways depend on level of tech side maturity required to analyze the task and your allocation:
   • Delegate to key developer, lead pr external possible expert to whom you might trust (i.e. project specialists).
   • [preferable] Assign dedicated role (i.e. architect) of the project to perform such actions and work to him only. Most slow but most mature way.
   • (in terms of our case) there was a good way to make a brainstorming session among every leads to make them agreed on position.
   • Write by yourself by at the level of I/O data, contracts, restrictions, metrics, quality criteria, test specs + risks (if any). but then share internal draft with the specialist to accept, confirm.
3. Progress trace.
   If this is a priority requirement – this is mandatory to check status daily, or bi-daily; or assign and manage a risk of tasks fail and prepare contingency like that was defined in our case.

Dev Leads mistakes:

1. Commitment to dates, interfaces and quality.
   This is the key. This is the job, goal, mission of every development team lead to manage by himself. Once committed – no way to change any from above.
2. Time of escalation – as early as possible.
   This is also important to know that there is no much worse in project issues as hiding or “smoothing” of the real problems and gaps in front of manager. As early DTL or _any_ within the team will escalate the issue he can’t address by his own – the easier resolution it will get.
3. “All for one and one for all”
   There is no bad and good peers. And working as a team among colleagues it’s necessary time to time to hide your aggression and try to walk in one’s shoes but get level of solid, robust, trustful relations within partners. Just try, no harsh, no rush – and you’ll see results.

Conclusion

To be able to manage remote teams as well as the local ones and get rid of the risks, make sure you:

1. When planning assignments get in count that team stakeholders are humans, not resources. Avoid getting in one boat person who thinks fast “(E)ntrepreneur” and likes adrenaline “Producer (P)” with calm person “Administrator (A)»;

   http://www.valuebasedmanagement.net/methods_paei.html
   http://www.12manage.com/methods_paei.html
   PAEI model of Adizes

2. Identify the detailed plan for the period you’d manage the team remotely – table/grid/Gantt charts (see bellow);
3. Assign key developers and define their requirements, responsibilities and quality metrics – in written format
4. Provide the team (or to key developers) with the definitions, goals and detailed requirements to mitigate the case of misunderstanding of their current job – in written format
5. Establish the pipeline of team deliverables’ verification – conf calls, reports – no matter, but key points are: periodical, mandatory and coming from responsible stakeholders, not from you.
6. Define proper communication flow – diagram or table.

Chicken Runaway!

The sad story happens when the big team (>25 team players) used to to be managed locally and then, by a matter of any reason, is going to be managed remotely for a certain period of time (e.g. business trip) – a case with the code-name «Chicken Run».

To figure out the pre- and post-conditions for that, the topic was written about. The business case being written for this article.

It happens when trying to catch up with distributed team about their statuses, the first item you’re realize that what you see is really similar to the story of little chickens that runaway every time the hen failed to stay tuned up i.e. everyone is somewhere, doing something and running away from the normal case…

It results on loose of the deliverables and quality and low team morale at the end when you’re begin to sound harsh on them.

What’s the crucial moments of that fact? How to avoid that case? Are there any risks that need to be addressed?

Pre-Conditions:

What’s actually happened that brought Team Leader/Manager to the fact of «chicken run».

For sure it could be caused by the «unprofessionally» staffed team, that simply can’t be managed up but… hold on for the second. Let’s first check the answers for the list below:

1. have you defined the detailed plan for the period you’d manage the team remotely?
2. have you assigned the key developers and defined their responsibilities?
3. have you provide the team with the definitions, goals and detailed requirements to mitigate the case of misunderstanding of their current job?
4. have you established the pipeline of team deliverables’ verification?
5. have you defined communication flow?

and more… and more.

So that basically means that against looking at the team weakness, there are more lead’s work-items that may be abandoned and since that cause the team to be self-managed and isolated from the overall project you’re working on.

Business Case:

Project XYZ has a development team around 16FTE at average being managed with the 4 DTL resources in regular office space. They are: James, very pedantic and accurate person, but a bit too nervous and selfish; John - very fast-minded person who admires no documentation and works on a runtime ‘thoughts’. John and James have a common parts of the project to coordinate. Rest 2 guys are Tom and Tim - both are experienced leads but doing focused parts of the projects. James, has a aversion to John, because considers him to be too fast and non accurate;

Project Coordinator (Sam) works onside with partners and monitoring progressed during a stand-up calls where talk with DTLs about the position of the progress being made; however the time difference (+4h) and high load of PC prevented normal schedule of these calls.
At Monday morning Sam was informed by the partner side that it’s an urgent work to be held during a week. Requirements were not formalized and scope of work had been only spoken b/w PC and partners.

Sam performs conf. call to assign new tasks and estimate the work as a 2 days for a team of 5 developers with the coordination by Jonh, then he tell to deliver an internal intermediate package to James to let him manage the integration of the sources into a product and release a build in 3 days;

On the conf. call Sam tells both lads to work closely together to get thins done in 5 days. He asked both to confirm that all is understood and after acceptance was taken the conf. call ended up with good willing of success.

In next 2 days Sam was busy with planning and was unable to call lads. He used IM to get the statuses and got from Jonh that all is done in time.

On the 4th day Sam talked to James about the progress and was shocked that the components which were written by John’s subordinates do not satisfy the interfaces assumed by James’s development team and now they’re re-writing the modules;

At the 4th day end Sam understands that only half of work being done and starts active verification of what’s being wrong. He asks his team to say in office and work to get the components written.

He did also ask John of why his team produced so weak result but got that «we’ve tried to simplify the work to get this done in time and I’ve decided to change the logic to speed up the delivery».

At the end of 5th day work was closed to get done but when partners saw the results they started argues that it’s completely not of what they’d assumed to achieve.

In next 2 days (sat/sun) team was working full days to rework the code…

Business Case Questions:

- what was done incorrectly by Sam?

- where were mistakes of John/James?

- what could be recommended to prohibit Sam’s story happens ever?

p. s.

In next article I would describe the resolution and provide comments on the case as above.