40 заметок с тегом

Управление проектами

Поймай меня, если сможешь. Версия директора

Взял с Хабрахабра: https://habr.com/ru/post/455178/
Автор: https://habr.com/ru/users/nmivan/

«Поймай меня, если сможешь». Так называется фильм Стивена Спилберга. Я смотрел, интересно. Но не правда, хоть и основано на реальных событиях.

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

Слышали, наверное, такое красивое высказывание: если вы пригласили на работу квалифицированного специалиста, то надо делать то, что он говорит, а не говорить ему, что делать. А вы пробовали делать то, что говорят эти квалифицированные специалисты? Я пробовал. И скажу прямо: это полная чушь.

На днях я выгнал очередного ИТ-директора. Вслед за ним, по неведомой причине, мой единственный программист сорвался и уехал в Москву, хотя я недавно поднял ему зарплату. Ладно, черт с ним, с программистом. Он раньше был хорошим, ценным, полезным, интересным, вдохновленным — тем самым квалифицированным сотрудником, которого хотелось слушать, и делать так, как он говорит. А потом, как и все, стал играть в игру «поймай меня, если сможешь».

Что за игра такая? Вы ее называете «работа», «выполнение своих обязанностей», «поддержание работоспособности ИТ-инфраструктуры», «автоматизация предприятия», «разработка веб-приложения» и т. д. Единственная ваша цель в этой игре — не быть пойманными.

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

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

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

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

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

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

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

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

Я — старый, больной человек, живущий в небольшом городе, работающий наёмным директором завода. Я очень далек от ИТ. Но за годы работы я запомнил несколько странных для меня слов. Вот послушайте: Водопад, Спираль, Канбан, Скрам, Джира, Трелло, 1С: Документооборот, Айтил и Итилиум (братья?), Майкрософт Прожект, Задачи в аутлуке, Директум, Битрикс24, Корпоративный портал, Яндекс Трекер, метрики, СЛА, тайм ту маркет. Я эти слова не просто запомнил — я пользовался этими системами, вникал в эти методики, как мог. Всю эту ерунду тащили ко мне ИТ-директоры.

Помните фильм «Служебный роман»? Каждый новый начальник начинает с ремонта своего собственного кабинета. А каждый новый ИТ-директор начинает с внедрения новой системы управления задачами, проектами и взаимодействиями. У меня есть подозрение, что они ничего другого делать не умеют. А, да, умеют — большинство из них — бывшие системные администраторы, умеют покупать новые серверы (получая откаты от продавцов), актуализировать карту сетей и трясти картридж, когда полосы появляются.

Мне еще повезло — корпоративную информационную систему внедрять не надо, уже давно мой программист с этим справился. Иначе каждый новый ИТ-директор предлагал бы автоматизацию затеять, позвал бы интегратора, те бы всё запороли за мои деньги, и в итоге всё равно пришлось бы нанять программиста, а ИТ-директора — выгнать, чтобы он искал очередного терпилу, получал от него зарплату, и откаты от интеграторов, поставщиков серверов и всего и вся.

Ладно, отвлёкся. Я точно знаю (теперь), что внедрение какой-бы то ни было системы управления задачами никак не помогает бизнесу. Тому, которым я управляю, не помогло. Просто задачи, которые надо делать, периодически перекочевывают из одной системы в другую. При переносе задачи получают индульгенцию — просроченные, по мановению волшебной палочки, перестают быть таковыми. Как мне объясняли, нельзя добавить задачу со сроком выполнения, который уже вышел.

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

Так ИТ-директор может протянуть целый год. И его не поймаешь, он ведь занят. У него задача.

Потом начинается эксплуатация. И всё возвращается на круги своя. Выполняются какие-то проекты. Решаются какие-то задачи. Появляется какой-то функционал. А с точки зрения бизнеса не меняется ничего. Нет, вру — затраты на ИТ растут.

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

Может, вы мне, дураку, объясните? Зачем, например, автоматизировать работу бухгалтера? Вот сидят пять бухгалтеров. Давно сидят. Еще когда система самописанная была, сидели. И справлялись со всей своей работой. Делали все необходимые операции, закрывали, сдавали отчетность, помогали оптимизировать налогообложение. Работали с 8 до 17.

А вот мы автоматизировали их работу. Купили современную информационную систему, переехали на нее, обучили бухгалтеров, начали работать. Они опять справляются со своей работой. Делают все необходимые операции, закрывают, сдают отчетность, помогают оптимизировать налогообложение. Работают с 8 до 17.

Вдруг, откуда ни возьмись, появляются задачи по автоматизации бухгалтерии. Тут им что-то надо доделать, там какую-то бумажку, здесь где-то что-то не заполняется. Ладно, ИТ делают — или сами, или внешних интеграторов зовут. Что в итоге? Сами понимаете. Бухгалтера по-прежнему справляются со своей работой. Делают все необходимые операции, закрывают, сдают отчетность, помогают оптимизировать налогообложение. Работают с 8 до 17. Да, и бухгалтеров по-прежнему пять.

В чем тогда смысл? Можете объяснить? С точки зрения бизнеса единственное, что произошло — я потратил деньги на автоматизацию. Всё, больше ничего. Людей меньше не стало, а значит — затраты не сократились. Никакой дополнительной работы они на себя не взяли. Скорость ввода и обработки операций не изменилась. Ничего не изменилось, только картинка на экране. А деньги, как говорится, уплочены.

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

Этот предложил создать систему самим. Мол, главная проблема покупных систем и сервисов — плохая кастомизируемость (вот, еще словечко в мой вокабуляр). Под эти системы надо подстраиваться, менять свои процессы, чем-то жертвовать, с недостатками мириться. А мы сделаем систему сами, по нашим требованиям, и всё взлетит. Я подумал, и согласился.

Что в итоге? Вообще, подозреваю, что он не разрабатывал систему, а где-то стырил — больно быстро она появилась. Презентовал мне, и показал ключевое преимущество — мы, говорит, будем ранжировать задачи с точки зрения полезности для бизнеса. Я, блин, в восторг пришел! Наконец-то появился человек, который понимает, что мне нужно!

Но радость была недолгой — минут пять. Пока мы не сели с ним эту самую полезность определять. Знаете, как это выглядит? Я, если честно, думал, что там какая-нибудь балльно-факторная оценка будет, мы введем кучу параметров, в т.ч. затраты на реализацию, и система нам что-то посчитает. Я о таком слышал на одной из конференций. А что у нас?

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

Я, конечно, сдержался, чтобы не засмеяться. Ну, говорю, кто же определит полезность задачи для бизнеса? Вы, говорит! Директор определит! Да твою ж за ногу… Помните, да? Делать, что говорят квалифицированные специалисты.

Ладно, попробую. Смотрим первую задачу — автоматизировать работу ОТК, перечень требований прилагается. Мда… Как оценить полезность этой задачи для бизнеса? Это я себе вопрос задал. Подумал немного — не знаю.

Спрашиваю у ИТ-директора — может, ты знаешь, как решение этой задачи повлияет на бизнес? Но он хорошо играет в игру, его не поймаешь. Начинает юлить, говорить про ускорение оформления операций, прозрачность учета, прослеживаемость партий… Стоп, говорю. Бизнесу что от ускорения оформления операций? Можно будет ОТК на сокращенный рабочий день перевести? Уволить кого-то из них? Дополнительные обязанности навешать?

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

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

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

Раз задачу отменил, значит не нужна автоматизация. Хорошо, кто ж против. А как, спрашиваю, Коля, ты можешь нашему бизнесу помочь? Коля молодец — я говорит, чё, плохо работаю, что ли? Почему ко мне претензии?

Да упаси Господь, Коля, какие претензии! Но у нас тут бизнес, и перед ним стоит задача — прибыль повысить. Всегда стоит такая задача. Иногда, не скрою, прибыль надо повысить до нуля. Вижу, что Коля занервничал. Ладно, решил сгладить ситуацию.

Обратился сразу к обоим — парни, говорю, вот вы — представители разных миров, квалифицированные специалисты в своем деле. Один проверяет железяки, другой покоряет виртуальные миры. Оба — менеджеры. Значит, не наивные институтки, всё понимаете. Бизнесу надо повысить прибыль. Такая задача. Решить ее могут только сотрудники — такие, как вы.

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

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

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

И тут меня осенило! Я понял суть этой игры! Вот почему я никогда не могу никого поймать! Я так обрадовался, что отпустил господ менеджеров — сказал, что подумаю над задачами для них.
Задача! Задача! Задача! Самое главное в этой игре — задача! Это тотем, иммунитет, бронь от любых неурядиц! Главное — чтобы у тебя была задача!

Пока у тебя есть задача, с тобой ничего нельзя сделать. Когда у тебя нет задачи, ты почти на плахе — ведь ты получаешь зарплату просто так. Ничто так не давит на психику, как отсутствие задачи на работе. Особенно, если отсутствие задачи — очевидное.

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

И нет никакой разницы, полезна задача бизнесу или нет. А если кто-то будет на эту тему возбухать (как я, например) — добавим ему поле «Полезность для бизнеса», пусть ранжирует. Человеку ведь без разницы, какую задачу выполнять первой, а какую — второй. Главное, что задачи есть, и их много.

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

А чем? Тут он начинает перечислять, а ты стоишь и чувствуешь, как у тебя уши вянут. Какой только чуши не расскажет! Предоставление информации, согласование предоставленной информации, проверка согласования предоставленной информации, анализ предоставленной информации, согласование анализа предоставленной информации, проверка согласования анализа предоставленной информации.

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

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

А самое поганое — никого ведь не поймаешь. Ну, найду я какую-нибудь тупую задачу. Скажу человеку, чтобы он больше этой ерундой не занимался. Что произойдет, как думаете? Ни-че-го. Отменили задачу? Сделаю ДРУГУЮ!

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

Я не знаю, как быть, если честно. Любой идиот, так же, как и Коля с ИТ-директором, скажут — для повышения прибыли надо увеличить продажи и снизить затраты. Кто-то, может быть, еще приплетет увеличение объемов производства. И всё. Это все рычаги, которые у нас есть.

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

И всем пофигу, у всех задачи. А повышать прибыль — задача директора. А директор не знает ИТ. Директор не очень знает финансы. В тонкостях бух.учета не разбирается. Производство понимает хуже, чем начальник цеха. Но директор должен поставить каждому из них задачу.

В формулировке директора («повысить прибыль») задача не годится. Всем нужно объяснение — как именно они могут повысить прибыль. Ладно, хоть никто кроме ИТ не просит тех.задания.

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

Я так не могу. И продолжаю ставить задачу так, как ее понимаю я. И никак не могу никого поймать. У всех задачи. А моя не годится. И постановка плохая, и времени на нее нет, и вообще — не задача это. Смартировать надо, хотя бы.

Приходится увольнять. Это всё, что я могу. И никакие аналитики не помогут — я пробовал. Они — такие же бездари, мечтающие о ЗАДАЧЕ. Приезжают, и раскладывают свои товары, как цыгане. Это вот — ТОС, это — ИСО, это — Lean, это — еще черт знает что. Выбирайте, оплачивайте, и будем внедрять. Что выберете, то и будет ЗАДАЧЕЙ.

Когда внедрят, получат расчет и уедут. Они решили задачу. Свою. Чего и добивались. А мою никто решать не будет. Надо как-то самому выкручиваться. Как всегда.

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

Надо дальше двигаться. ИТ-директора я уволил. Думал обойтись одним программистом — зачем ему прослойка в виде ИТ-директора? Но парень в Москву свалил. Буду другого искать.

Этот еще чудик из головы не идет, как его… А, Король. Странная кличка. Завтра встреча, а я понятия не имею, кто он и что ему нужно. Говорит, что это — в моих интересах. Схожу, что уж.

Может, он мне задачу поставит. Тоже поиграю.

2019   Люди   Управление проектами

WSJF как способ приоритезации задач

Weighted Shortest Job First. Сначала наивесомейшая кратчайшая работа.

Принцип используется в SAFe 4 как метод приоретизации работы. Смысл в том, чтобы наиболее ценные и быстровыполнимые задачи брать с более высоким приоритетом. Для того, чтобы быстрее наносить максимум пользы конечным пользователям в потоке поставке ценности.

Что глядя на это можно сказать?

  • Чем скорее можем поставить большую ценность, тем лучше.
  • Чем меньше потратим Cost of Delay, тем лучше.
  • Чем менее значима бизнес составляющая, и высока сложность, тем меньше шансов, что до её реализации вообще дойдет :)

Звучит очевидно, да? Но на практике не всегда легко ранжировать.


Формула выглядит так:

WSJF = Cost of Delay / Duration

SAFe предлагает Cost of Delay считать как:

Cost of Delay = User-Business Value + Time Criticality + (Risk Reduction or Opportunity Enablement)

  • User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
  • Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
  • Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
  • Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Оценки проставляются от 1 до 21 согласно ряду Фиббоначи (1, 3, 5, 8, 13, 21... ), суммируются и делятся на размер работы. Размер работы тоже оценивается числами Фиббоначи, в общем оценкой в скрамовских сторипоинтах.

К примеру, следующий набор Фич для интернет-магазина:

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

Проведем оценку, чтобы было понятно почему такие значения, распишем Business Value и перечень технических задач на реализацию каждой Фичи:

Есть строгие правила проставления оценок:

  1. Заполнять по одной колонке за раз, начиная с самой простой Фичи, проставив ей оценку 1, остальные оценивать относительно первой единице
  2. Следствие: должна быть минимум одна единица в каждой колонке!
  3. Самое большое число по WSJF означает наиболее высокий приоритет
    По мне, очень полезные правила, придерживаться которых следует, чтобы снизить коэффициент «ленинского прищура».

Расставляем веса и смотрим что получилось:

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

Самое ценное в этом принципе то, что его использование предполагает диалог между бизнесом и инженерами.

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

А вот мой двухгодичной давности пост о приориетизации http://ashigabutdinov.ru/2016/02/07/1/

Вперед, к причинению пользы! ;-)

Еще по теме:

  1. http://www.summa.com/blog/what-is-wsjf-how-to-use-this-agile-concept-to-prioritize-work
  2. https://techbeacon.com/prioritize-your-backlog-weighted-shortest-job-first-wsjf-improved-roi
  3. https://www.scaledagileframework.com/wsjf/
2018   SAFe   Управление проектами

Как косячить

Илью зовут на вечеринку в 20:00. Чтобы успеть, Илья должен выйти с работы в 19:00. Попросили по дороге заехать за пиццей. «Успею», — думает Илья.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки, приедет он с опозданием на час-полтора. Но Илья никому не звонит, потому что не хочет краснеть перед друзьями.

19:35 «Да и потом, это ж вечеринка, никто не приходит вовремя, да и все знают, что в городе пробки».

19:40 «И они могли бы и раньше меня позвать, я бы как-то лучше распланировал свой день».

19:50 Илье пишут друзья: «Ну что, ты где?». Илья видит уведомления, но не открывает их, чтобы не было галочки «прочитано». Неудобно, что он так поздно выехал.

20:10 Друзья звонят. Илья не берет трубку, зная, что придется краснеть.

20:30 Илья придумывает шикарную отмазку и перезванивает: «Только вышел с совета директоров, эти дебилы никак не отпускали, еле вырвался. Извините, всё, сейчас прыгну в машину и приеду к вам».

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

21:30 Илья появляется на пороге. До него уже успели заказать пиццу и ее только что привезли. Несмотря на полные пакеты и дикие извинения, Илью принимают холодно.

00:00 Большая часть закусок и пиццы остыла и высохла до того, как к ней успели притронуться.

Что в итоге. Илья потратил кучу денег, подпортил отношения и из-за него высохло четыре невинные пиццы.

Или нет, погодите. Всё было не так.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки. Илья переборол стыд и звонит друзьям: «Ребзя, я опаздываю, извините, буду во столько-то. Могу рвануть на метро, но тогда не смогу заехать за пиццей». Друзья в один голос: «Ой, да плевать на пиццу, приезжай скорее. Пиццу закажем».

20:10 Илья выходит из метро и звонит друзьям: «Тут возле выхода есть универмаг, у них должна быть замороженная пицца, взять?» Оказывается, пиццу уже заказали, но нужно докупить выпивки. «И чипсов!» «И сладенького!» «И на завтрак ничего нет!» «И туалетной бумаги десять рулонов!»

Ну, бывает.

20:30 Илья появляется на пороге с пакетами. Его встречают, как героя. Как раз все в сборе.

Что в итоге. Илья потратил немного денег, и хотя он закопался на работе и опоздал, все кайфанули.

Замените вечеринку на статью, друзей на клиентов, пиццу на интервью с экспертом, пробку на творческий кризис, а «восемь вечера» на «дедлайн» — получится редакторский проект. Замените на дизайн в соответствии с брендбуком — будет проект с дизайнером. Задача по работе мало чем отличается от задачи для друзей.

Мораль

Как грамотно косячить на проекте:

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

Приходить с решением. Не просто «опаздываю», а «опаздываю, предлагаю заказать пиццу по телефону».

Оставаться на связи, даже если стыдно. Чаще всего клиенту нужно не отчитать вас, а составить план. Вот вы накосячили, признали вину, что дальше? Может быть, не заезжать в пиццерию, а забежать в магазин у метро? Пока вы на связи, вы с клиентом одна команда. А как только пропадаете, вы превращаетесь в безответственного фрилансера.

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

Делать не то, что можешь, а то, что нужно. Есть распространенная ошибка: редактор сорвал срок и решил, что теперь-то он не имеет права на ошибку. Он решает вылизать статью до совершенства (все еще не отвечая на звонки).

Расчет такой: «Я уже опоздал, зато когда они увидят мою статью, они всё простят, ведь это будет лучшая статья в мире». Но клиенту нужна хоть какая статья сегодня-завтра, потому что послезавтра журнал уходит в печать. Через три дня ему статья не нужна, даже лучшая в мире.

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

Совсем мораль

Если коротко, то правила на самом деле три:
1. Общаться, а не молчать. Все проекты ломаются тогда, когда люди начинают делать каждый свое, не не держа друг друга в курсе. Видите проблему, даже со своей стороны, — сообщайте о ней. Вместе с клиентом вы придумаете, как ее решить.

2. Помогать, а не увольняться. У многих, когда они косячат, включается комплекс отличника: «как же так, я что-то сделал плохо, я плохой, я недостойный, сейчас меня уволят». Это ерунда. Клиенту наплевать, хороший вы или плохой. Ему надо решить задачу, и ваш косяк — просто обстоятельство.

Представьте, что это не вы накосячили, а кто-то другой. Что с этим делать? Как получить полезное действие в этих новых условиях? Придумайте решение и идите с ним к клиенту.

3. Не быть бараном. Накосячили — признайте, не оправдывайтесь. И чините, а не ждите, что всё исправят за вас.

Источник: Ильяхов

Полезное по теме
Начитаются кемпами и травят леску за гаражами

2018   Люди   Полезное   Управление проектами

Про скорость разработки в Канбан

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

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

Частая картина в девелоперских командах:

  1. Программист взял Задачу 1 в разработку
  2. Отправил Задачу 1 на тестирование
  3. Тестер приступил к тестированию через 5 часов
  4. Программист пока взял Задачу 2
  5. Задача 1 вернулась с багом
  6. Программист решает закончить Задачу 2
  7. Через 3 часа программист отправляет Задачу 2 на тестирование
  8. Программист возвращается к доработке Задачи 1
  9. Через час исправляет баг и отправляет Задачу 1 на тестирование
  10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
  11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

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

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

Так вот, в моих командах, процесс устроен следующим образом:

  • Ограничение WIP = кол-во девелоперов на проекте
  • Пока программист реализует задачу, тестировщик ждет: читает хабр, доки, занимается планированием собственной работы, какими-то улучшениями, общением с аналитиками по задачам в разработке
  • Как только задача готова, тестировщик принимается за ее тестирование.
  • Программист находится в активном ожидании обратной связи от тестировщика и читает хабр, документацию, занимается самосовершенствованием, помогает тестировать
  • Как только задача возвращается на доработку — берет ее в ту же минуту и быстро исправляет недочеты. Это легко, т. к. программист находится в контексте задачи и прекрасно помнит что именно где править
  • Как только задача завершена, тестировщик в ту же минуту проводит повторное тестирование, и если все ОК, отправляет в релиз.
  • Как результат:

    1. минимальное время на реализацию задач
    2. минимальное количество задач погрязших в болоте доработок
    3. у программистов и тестировщиков есть время на саморазвитие
    4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

    + Полезное из переписки на facebook:

    2017   kanban   Полезное   Управление проектами

    On demand maniac support

    Когда обратная связь от наших технарей ну очень быстрая :-)

    2016   Люди   Управление проектами

    О противопоставлении project-ов и product-ов на примере бабушек

    © Иван Селиховкин
    https://www.facebook.com/ivan.selikhovkin/posts/10207032631638700

    Давешнее. Давайте объясню что думаю о противопоставлении project-ов и product-ов на примере бабушек?

    У вас есть ребенок. Его надо регулярно укладывать спать. Ваша задача — чтобы он научился это делать самостоятельно (в идеале — оказался в кроватке, похлопал глазками и задремал).
    А у ребенка — бабушка. Любящая и самоотверженная. Она помогает.
    Вы решаете делегировать одно или два “укладывания” — ей.

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

    Когда бабушка — иначе. У нее на первом месте — лишь бы малыш не рыдал (она его любит, она не так уж много проводит с ним времени, поэтому укачивать на руках — лично ей не особо и трудно). Кроме того бабушка — боится, что если дитя будет часто плакать в ее “дежурство” вы перестанете ей доверять.

    В итоге из 6-7 укладываний — одно или два за бабушкой, которая подхватывает, баюкает малыша на каждый всхлип. Ребенок существо смышленое — быстро привыкает и скоро на меньшее уже не согласен.

    Если представить, что я говорил о бизнесе, то бабушка — это project manager. Мотивированный, добросовестный, и по формальным результатам у нее все не плохо (ребенок засыпает быстро). Но она делает не то что надо. Цели разные, своих бабушка достигает, вашим отчасти противоречит.

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

    Лет десять назад “лекарством” являлись KPI. Бабушке нужно было объяснить, что важно не укладывать быстро, а укладывать + не брать на ручки + не петь колыбельную (и растолковать почему это важно — ведь через год малыш станет неподъемным, а на колыбельные уже голоса не хватит). Работодатели объясняли “бабушкам” (рисовали сбалансированные показатели на уровне стратегии, спускали ниже, привязывали к выплате бонусов). Но менеджеры работали все равно по-своему (только теперь у них было одной заботой больше — скрыть как именно они “баюкают малыша”). Несовпадение целей одними только KPI-ми не лечится.

    Сейчас распространена уверенность — project не нужен, заведем product-a.

    И появляется бабушка-product manager. Ее ответственность не ближайший результат (уложить ребенка) а долгосрочный (обеспечить чтобы через пол года он спал сам). Или в случае с уроками — не проверять домашку, а обеспечить, чтобы он научился сам получать знания, поступил в ВУЗ и в конечном счете нашел работу мечты (своей мечты, не вашей).

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

    Вот только бабушке от этого не легче. Вы только что делегировали ей ответственность за мало понятный результат. Не каждая бабушка доживет (хотя дай ей бог здоровья) до выхода внука на работу (равно как и не каждый product в вашей компании дождется снискания своим детищем коммерческого успеха). Бабушке, порой, не ясно как измерять промежуточные успехи (сегодня внук делал домашку лучше, завтра хуже, а потом снова хорошо; из школы принес то двойку то пятерку — это что вообще значит, он приблизился к работе мечты или нет?)

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

    Для подобных проблем больше давным давно придумали термин “агентская проблема”. И абсолютного решения так и не нашли.

    А противопоставление product-ов и project-ов не имеет смысла.

    Project-ы и product-ы — две приходящие бабушки, противопоставляющие себя друг другу.

    Самоуверенно спорят кто лучше влияет на малыша. А бизнес, поглядывая недоверчиво на результат, пытается подобрать новые слова. Бирюзовый, бирюзовый, бирюзовая семья, родители, бабушка — бормочет он неуверенно.

    2016   Полезное   Управление проектами

    Выбирайте выражения

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

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

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

    Aggression

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

    — «Внесите в ваш белый список наши новые IP-адреса, с которых мы будем обращаться к вашему API»

    — «Нужно внести в ваш белый список наши новые IP-адреса, с которых мы будем обращаться к вашему API»

    — «Когда пришлете запрошенный список активных сервисов?»

    — «Когда можем ждать запрошенный список активных сервисов?»

    Восток дело тонкое.

    Imperio!

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

    «Можете, пожалуйста, посмотреть, есть ли привязка префиксов к указанным id сервисов и прислать их список?»

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

    «Пожалуйста, посмотрите есть ли привязка префиксов к указанным id сервисов и пришлите их список»

    Strike

    Некоторые наши HR являются потрясающими коммуникаторами и иногда бомбят меня конструкциями вроде:

    — Можешь сказать время, когда ты будешь готов встретиться с Леонидом Гудковым?

    Да, конечно, могу сказать, язык же есть. Называю время и автоматически подписываюсь на то, что встречаюсь с господином Гудковым, хотя может быть я и не хотел вовсе :-)

    2016   Люди   Полезное   Управление проектами

    Про типы личности по Адизесу

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

    • P. Производитель — нацеленный на краткосрочные результаты
    • A. Администратор — нацеленный на процессы и эффективность
    • E. Энтерпренер (предприниматель) — нацеленный на долгосрочные результаты и видение перспектив
    • I. Интегратор — нацеленный на эффективное взаимодействие людей в компании и блгоприятную психологическую атмосферу

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

    Более подробно:
    Типы руководителей
    Стили управления PAEI
    Тест на тип личности по Адизесу
    Funky и Sexy менеджеры

    2016   Книги   Люди   Полезное   Управление проектами

    Встречи 1 на 1 с сотрудниками

    Каждые 3-4 недели рекомендуется проводить встречи 1 на 1 с сотрудниками для того, чтобы снять их текущее состояние, выявить проблемы, обсудить какие-то накопившиеся вопросы.

    Встречи проводятся для того, чтобы говорил сотрудник, а не менеджер. Обычно провожу диалог со следующим набором вопросов:

    1. Интересны ли задачи которые ставятся? Не слишком сложные? Не слишком простые?
    2. Есть ли какие-то проблемы, которые ты видишь, которые нужно решить?
    3. Есть ли у тебя какие-то идеи как можно улучшить в проекте или команде? Может в компании в целом?
    4. В какой области есть желание развиваться?
    5. Время от времени люди смотрят вакансии в других компаниях, все ли тебя устраивает?
    6. Как тебе взаимодействие с ребятами? Все норм, конфликтов нет? (Поименно) А с Васей? А с Петей? А с Машей?
    7. Если есть проблемы: Есть ли у тебя идея, как следует эту проблему решить? Можешь предложить способ решения, который бы всех удовлетворил?
    8. Накопились ли какие-то вопросы на которые могу ответить?

    Смотреть в глаза, записывать что говорит собеседник.
    Основная цель: снять состояние человека, понять что человеку нравится или не нравится, помочь решить какие-то проблемы.

    На таких встречах иногда возникают какие-то идеи или принимаются решения что-то сделать, в этом случае

    • каждый вопрос нужно доводить до состояния КТО / ЧТО / КОГДА будет делать
    • все договоренности записываются
    • все договоренности выполняются после встречи 1 на 1
    • на следующей встрече подводятся итоги того что было сделано по результатам прошедшей встречи

    Для меня эти встречи — инструмент для выявления в каком состоянии находится сотрудник:

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

    Отличное состояние. Устойчивое, интересное.

    Потом человек делает то, что умеет год или два. Опыт накоплен. Задачи решаются. Но интерес постепенно спадает. Сдвигаемся влево. Человек знает и умеет, возможно, больше всех в команде или компании. От работы немного «укачивает», но авторитет, должность, деньги и зона комфорта могут удерживать человека достаточно прочно.

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

    Александр Орлов про формулу работы с людьми

    MindMap по Формуле работы с людьми (xmind) — как раз из видео
    http://stratoplan.ru/pmf/stratoplan_pmformula.xmind

    2016   Люди   Управление проектами
    2016   Управление проектами
    Ранее Ctrl + ↓