Где прячутся неприятности на программных проектах

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

Источник

Неисполнимая мечта...

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

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

Но не сегодня. Вот например, каждый правильный руководитель проекта, учитывая все риски, заранее составляет планы всех-всех работ в Microsoft Project. Красивые такие диаграммы Ганта... Я об этом знаю наверняка - мне об этом рассказывал мой старый товарищ - сертифицированный Project Management Professional. Я с ним до пандемии часто на работу вместе ездил. Я на мой перманентный аврал мою любимую работу, а он - курсы по PMBOK читать. Вот и было время обсудить как правильно управлять проектом.

По мотивам

Вы думаете, я не пробовал? Сколько раз. Сначала я думал, что может то ли версии Microsoft Project мне попадалась неправильные, то ли проекты. Но потом я понял, что проблема во мне и по всей видимости мне ее не решить. Не в этой жизни. И со SCRAM на моих проектах тоже почему-то отношения не складываются ...

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

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

Устраивайтесь поудобнее. В этой сказке статье “многа букафф”...

Игра слов

Во дни сомнений, во дни тягостных раздумий о судьбах моей Родины, — ты один мне поддержка и опора, о великий, могучий, правдивый и свободный русский язык!

Иван Тургенев

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

Вот, например, по меткому замечанию Максима Дорофеева, срок – это дата до которой задача точно не будет решена. Замечание справедливое, однако вряд ли подойдет для планирования работы проектной группы.

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

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

По мотивам

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

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

• Рабочее время сотрудника – период времени в течении которого сотрудник должен может исполнять свои обязанности согласно трудового договора.

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

• Бюджет рабочего времени сотрудника – сумма интервалов рабочего времени сотрудника в рамках заданного календарного периода. У одного сотрудника это 40 часов в неделю. А у другого - 10. При этом для каждого сотрудника может быть характерен свой распорядок рабочего времени – один сотрудник работает в будние дни с 9.00 до 18.00 с перерывом на обед с 13.00 до 14.00 по московскому времени, а другой только по четным дням календаря с 12.00 до 20.00 без перерывов.

• Время оказания услуг – период времени в течении которого, согласно договора, исполнитель гарантирует проведение работ по решению требований заказчика. Например с 9.00 до 18.00 по московскому времени в будние дни согласно производственного календаря, утвержденному Правительством РФ. Или другой вариант – 24/7/365.

  < /li>

• Срок решения (выполнения) задачи – дата, до истечения которой задача должна быть решена, т.е. переведена из статуса «назначена» в статус «контроль» (в терминологии БД JIRA - DUEDATE) . Под статусом «контроль» подразумевается состояние задачи, когда с точки зрения исполнителя все работы по ней полностью завершены и фиксируется готовность к сдаче/приемке результатов этой задачи заказчиком (результат отгружен на склад готовой продукции).

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

• Трудоемкость задачи – объем рабочего времени, запланированный из бюджета рабочего времени сотрудника для выполнения работы (решения задачи) в полном объеме (в терминологии БД JIRA - TIMEORIGINALESTIMATE).

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

• Трудоемкость, необходимая для завершения задачи – рабочее время, необходимое по оценке ответственного исполнителя для завершения задачи с учетом ранее выполненной работы (в терминологии БД JIRA - TIMEESTIMATE).

• Трудозатраты по задаче – фактическое рабочее время, потраченное (списанное) ответственным исполнителем для решения задачи (в терминологии БД JIRA - TIMESPENT).

• Календарная продолжительность выполнения задачи – сумма интервалов календарного времени нахождения задачи-работы в статусе <назначено> (с учетом выходных и праздничных дней).

• Проектная продолжительность выполнения задачи – сумма интервалов нахождения задачи-работы в статусе <назначено> в рамках рабочего времени по договору (например, время предоставления услуг согласно договору с 9.00 до 18.00 по будним дням ).

• Табельная продолжительность выполнения задачи – сумма интервалов нахождения задачи-работы в статусе <назначено> в рамках периодов рабочего времени сотрудника (с учетом условий трудового договора, отпусков, больничных, отгулов и т.п.).

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

Поэтому, чтобы “с водой не выплеснуть ребенка”, обычно для новых сотрудников нашей проектной команды я поясняю эти определения “на пальцах”. С помощью метода Ильи Франка. В студенческие годы я иногда подрабатывал грузчиком. В разных организациях. Довольно быстро выяснилось, что зарабатывать деньги с помощью интеллекта, сложнее, но более эффективно и комфортно, чем с помощью мышц. Онако с тех времен, осталась привычка объяснять производственные процессы на простых примерах.

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

По мотивам

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

Склад работает с разными клиентами по разным договорам. Эти договора предусматривают разное время оказания услуг. Одни машины могут быть обслужены только с 9.00 до 18.00 по будням, а другие в любое время суток. Поскольку условия договоров разное, то время нахождения машин на стоянке тоже разное. При этом различается календарная продолжительность нахождения машин на складе и проектная продолжительность(продолжительность в рамках времени оказания услуг по договору). Поэтому, если время предоставления услуг согласно договору с 9.00 до 18.00 по будним дням, то для машины прибывшей на склад в 17.00 в пятницу на 10.00 понедельника, календарная продолжительность нахождения на складе составляет 65 часов, а проектная продолжительность - 2 часа. И при этом если машина находится на стоянке склада – это не значит, что все это время ее будут обслуживать. Обслуживать ее будут только в рамках графика рабочего времени назначенных сотрудников, назначенных на выполнение этой задачи. Поэтому, табельная продолжительность нахождения задачи в работе, как правило еще меньше чем проектная. С другой стороны, если на сотрудника назначена задача, это еще не значит что он все бросит и начнет ее сразу выполнять.

Плановое время загрузки/разгрузки – трудоемкость – вполне предсказуемо и отличается для полуторатонной “ГАЗели” от Камаза-рефрежиратора. Вместе с тем реальные трудозатратына обслуживание одного автомобиля гут существенно отличатся от запланированных. Случается, что не доразгрузив одну из машин, ставят задачу разгружать другую. Но на основе фактических трудозатрат на первую мошину, можно более точно определить трудоемкость, необходимую для завершения этойзадачи. Исходя из трудоемкости,с учетом времени оказания услуг по договору можно запланировать предельный срок выполнения задач по загрузке/разгрузке машин.

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

Однако мой опыт говорит о том, что 80-90% задач на программном проекте можно свести к этой простой модели (как я решаю оставшиеся 20% задач я поделюсь по ходу своего рассказа).

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

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

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

Распределение ресурсов

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

Клейтон Кристенсен

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

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

Было бы, конечно, здорово если бы кто нибудь опроверг мои наблюдения и рассказал о своем потрясающем опыте применения Microsoft Project на программном проекте. А то какой-то диссонанс получается между огромным количеством учебников и курсов по Microsoft Project и количеством статей на Хабре посвященным успешному успеху опыту применения этого продукта.

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

Задача подгонки параметров программного проекта под параметры руководителя и совокупной производительности команды этого проекта в настоящее время зачастую носит гордое название Agile-подхода. Как правило, эта задача решается принятием внешних ограничений. Будем есть слона по кусочкам. Например, ограничений SCRUM – мы будем делать фиксированное количество задач в рамках фиксированного спринта. Если количество задач изменяется – текущий спринт анулируется, и мы должны спланировать новый. Или ограничения КАНБАН – на одного исполнителя одновременно нельзя назначать более 2-3 задач. И самое главное ограничение – прямо таки сильно нежелательно увеличивать количество сотрудников команды более 12 человек.

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

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

Поскольку я давно потерял надежду спланировать задачи так, как это описано в правильных учебниках, я планирую сроки как получится. В рамках реализации одной требуемой функции еще удается связать задачи между собой и соотнести их сроки выполнения, но это все на что я способен. Указание сроков выполнения несвязанных задач первоначально осуществляется примерно, «на глазок». Я обычно стараюсь планировать срок выполнения любых задач не раньше, чем через неделю. Задачу, с запланированной трудоемкостью в 2 дня, ответственный сотрудник решит как нибудь за неделю . Ну и для других задачи так же назначаю сроки, по мере поступления. Но если бы все задачи которые надо решить были известны заранее... А по жизни они сыпятся как работа на Золушку. То заказчик требования поменяет, то ошибка непредвиденная влетит. Вот и получается что задачи разработчику ставит не только руководитель его проекта, а еще и разные аналитики, от группы сопровождения вопросы прилетают. То вдруг позвонит мне директор департамента и скажет: «У твоих коллег проект горит, пускай Вася Сидоров им поможет... У нас все-таки матричная система управления...».

В определенный момент времени оказывается, что бюджета рабочего времени программиста по любому не хватит чтобы выполнить все задачи в срок. Даже если трудоемкость этой задачи была оценена верно. Если вы пользуетесь правильными плагинами для JIRA, такими как Tempo Planer, вы в такую ситуацию не попадете. Наверно. Ведь этот плагин просто не позволит назначить задачу на сотрудника, если трудоемкость и планируемые сроки выполнения конфликтуют с имеющимся ресурсом. Но, как вы понимаете, правильные плагины - они для правильных менеджеров. Как вы поняли, я не отношусь к их числу...

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

«Нетипичный» случай

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

Юрий Шевчук

Для наглядности придумаем какой нибудь нетипичный кейс.

Жил-да-был программист Сидоров Василий. Считалось, что работает он по 8 часов по будним дням. Так случилось, что Сидоров незаменим одновременно в двух программных проектах. Проектом PI руководил Иванов И.И., а проектом PP – Петров П.П. Между руководителями была договоренность о разделении пополам между проетами бюджета рабочего времени Сидорова.

Однажды в понедельник, 30.11.2020 стали сыпаться на Сидорова задачи в JIRA. Прямо с 9 часов утра. Каждые полчаса – новая. То один руководитель задачку подкинет, то другой. Еще ладно, первую задачу по проекту PP Сидоров сразу отфутболил в ожидание, потому что сведений для решения не хватало, а вот другие отфутболить не получилось. Еще одну задачку (PP-13) Петров зарегистрировал, но в исполнение не перевел. Прямо как домоклов меч. Может свалиться в любой момент.

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

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

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

Сидоров парень исполнительный. Всем можно спать спокойно. Или нет?

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

Предварительные ласки

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

Основные тезисы этого подхода:

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

По мотивам

2. Для всех типов задач и подзадач используется типовой набор статусов и единый унифицированный рабочий процесс (workflow). При этом рабочий процесс отражает не бизнес-процесс, а жизненный цикл выполнения работ.

3. Ответственный исполнитель отвечает за решение задачи только в том случае, если она находится в статусе <назначено>. После ее решения он переводит задачу в статус <контроль>, после чего задача переходит в зону ответственности автора задачи.

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

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

Кроме этого, для того чтобы управлять ресурсами, необходимо знать сколько этих ресурсов есть в наличии. Конечно, можно оттолкнутся от того, что каждый сотрудник должен работать каждый будний день всегда по 8 рабочих часов. Возможно, если ваша команда состоит из андроидов, которые не болеют, не ходят в отпуск, не имеют детей, с которыми в рабочее время надо сходить в поликлиннику, не берут отгулов для того чтобы решить личные дела в МФЦ, не работают по совместительству на 3 работах, то, несомненно, это будет правильным подходом.

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

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

Измерение перегрузки

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

Максим Дорофеев

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

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

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

Источник

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

Панель фильтров предоставляет возможность выбора задач назначенных на сотрудника всего по трем атрибутам – типу задач, статусу выполнения задач и их приоритету. При этом поле статуса содержит возможность выбора всего из трех статусов: <оценка>, <в работе> и <ожидание>. Решенные задачи или находящиеся на контроле выполнения, дашбордом не учитываются.

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

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

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

• должен быть зарегистрирован ответственный исполнитель;

• должен быть установлен планируемый срок исполнения задачи;

· задача должна находится в одном из трех статусов: <в работе>,<ожидание> или <оценка>.

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

В группе колонок < Распределение бюджета рабочего времени сотрудника по срокам> отображается:

• Срок- планируемый срок выполнения задачи. Если текущая дата позднее запланированного срока, то данная ячейка подсвечивается розовым цветом. Все остальные показатели этой группы колонок формируются относительно значения этой колонки и текущей даты.

• Доступно– бюджет рабочего времени сотрудника, доступный на дату запланированного срока решения задачи

• Суммарная трудоемкость– суммарная трудоемкость нерешенных задач сотрудника на дату запланированного решения срока (с учетом зарегистрированных трудозатрат).

• Резерв – резерв бюджета рабочего времени сотрудника на дату запланированного решения – дату срока. Если резерв меньше 80% общего доступного бюджета времени ячейка подсвечивается желтым цветом (что бывает если вы начнете загружать своих сотрудников более чем на 80% хорошо объяснила Елена Федурко в одной из своих лекций ).

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

В группе колонок <Состояние по задачам>для каждой задачи выводятся следующие сведения о ее текущем состоянии:

В колонке <Дата создания> отражается время создания задачи. В случае если время создания задачи более позднее, чем запланированный срок ее выполнения данное значение подсвечивается красным.

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

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

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

В колонке <Перенос> отражается через слеш:

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

– Количество возвратов из статуса контроль. При наведении курсора на цифру выводится всплывающая подсказка со списком записей о времени/дате возврате задачи в статус <в работе> или <ожидание>.

– Количество возвратов из статуса закрыто(эксгумация задачи). При наведении курсора на цифру выводится всплывающая подсказка со списком записей о времени/дате возврате задачи в статус <в работе> или <ожидание>.

В колонке <Код и тема задачи> отражается пиктограмма характеризующая тип задачи (при наведении на нее курсора выводится всплывающая подсказка с наименовнием типа задачи), код проекта и номер задачи (или подзадачи) в проекте (ссылка на JIRA), тема (резюме) задачи и в квадратных скобках ФИО автора задачи. В случае выявлений нарушений планирования ФИО автора задачи выделяется цветом:

· красным – в случае срыва сроков или если время создания задачи более позднее, чем запланированный срок ее выполнения;

· оранжевым – в случае иных предпосылок к срыву сроков выполниния в связи с качеством и оперативностью планирования (нахождение задачи в статусе <оценка> или <ожидание>).

В группе колонок <Статус> отображается:

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

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

В колонке <Трудоемкость/трудозатраты/необходимо> - в этой колонке через слеш выводится три интегральных значения характеризующих степень выполнения задачи:

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

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

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

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

Диагнозы и рецепты

При попытке впихнуть невпихиваемое:
1) выпихивается ранее впихнутое;
2) уменьшается предел впихиваемости.

Максим Дорофеев

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

По мотивам

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

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

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

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

С другой стороны, за планирование и согласование сроков реализации задачи отвечает прежде всего автор создавший задачу.

По мотивам

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

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

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

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

Источник

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

Среди этих «бесчеловечных» способов управления наиболее эффективны:

– согласование и перенос сроков выполнения менеее приоритетных задач;

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

– cогласование проектных решений с исполнителями до отправки этого проектного решения заказчику;

– согласование планируемых трудозатрат с исполнителем, на основе детализации работ с использованием калькуляторов PERT ;

– согласование с заказчиком сроков выполнения задач с учетом текущей загрузки привлекаемых сотрудников, после согласования проектного решения и проведения оценки трудоемкости необходимых работ;

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

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

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

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

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

Правила приоритизации

Разговор о предотвращении неприятностей был бы неполным, без упоминания такого проклятия инструмента, как приоритезация. Многие руководители проектов, как и многие исполнители, считают, что в случае если задача имеет более высокий приоритет, именно её всегда надо выполнять в первую очередь, бросив все остальные работы. Мало кто задумывается, как такой подход может отразится на совокупной пропускной способности всей системы по реализации требований заказчика. С другой стороны, многие руководители считают своим долгом определить для исполнителей время когда этот исполнитель должен начать работать над решением задачи. Обычно, такие руководители думают, что только они могут правильно расставить последовательность выполнения задач. Как же иначе? Ведь без указания времени начала работ невозможно построить диаграмму Ганта. В Microsoft Project вообще нельзя зарегистрировать работу без указания планируемого времени ее начала и окончания.

Источник

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

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

На мой взгляд освещенные проблемы с приоритетами вызваны в первую очередь непониманием того, как использовать эти приоритеты акромя первого (бросай все, беги тушить). Зачастую назначение приоритетов задач в jira отождествляют с уровнями SLA договора по соответствующему проекту. В результате в одном проекте 3 уровня приоритета а в другом - пять. При этом исполнители, как правило, справедливо считают, что если поступает задача с более высоким приоритетом надо выполнять в первую очередь ее. Такой подход при определенных обстоятельствах может полностью заблокировать выполнение потока задач. Я на своих проектах давно применяю другие правила, принятые кстати при обработке потока сообщений на узлах связи. Эти правила основаны на том, что задачу выполняет один станок сотрудник и одновременно он может выполнять только ОДНУ задачу. Все были на приеме у врача в обычной поликлинике? Вспомните - есть общая очередь по записи (3 приоритет), есть очередь с острой болью (2 приоритет - если врач один, этих бедолаг обслуживают через-одного-из общей очереди), иногда внезапно кто-то в белом халате приводит откуда-то пациента которого обслуживают поперек всяких очередей (1 приоритет). А если вы найдете общий язык с врачом, он может предложить вам прийти вечером, когда народу поменьше (4 приоритет). При этом при планировании задач на сотрудника сроки(deadline) выставляются таким образом чтобы загрузка по 1,2,3 приоритетам не превышала 80% бюджета рабочего времени исполнителя. Такой подход позволяет обеспечивать решение текущих задач исполнителем в заданные сроки не блокируя потока производства и кроме того, позволяет решить проблему "проклятия приоритезации", делегируя на исполнителя принятие решение о последовательности выполнения поставленных задач.

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

Прежде всего для каждой из выполняемых задач-работ на проекте установлено четыре уровня приоритета:

– 1 приоритет – вне очереди (нужно все бросить и заниматься только решением этой задачи).

– 2 приоритет – решается в первую очередь;

– 3 приоритет – обычный;

– 4 приоритет – решается при наличии свободного рабочего времени (но, как правило, не менее 1 часа в рабочий день);

Обычно, наличие у сотрудника задач более высокого приоритета «закупоривает» выполение сотрудником всех остальных задач. Для нашего проекта это справедливо только в случае наличия у сотрудника в работе задач 1 приоритета.

В остальных случаях, при одновременном нахождении в работе нескольких задач разного приоритета сотрудник должен тратить на решение задач более высокого приоритета не более 60% общего рабочего времени. По тому же принципу делится оставшиеся 40% бюджета времени. Например, в работе есть три задачи 2, 3 и 4 приоритетов. Все задачи трудоемкостью более 8 часов. В этом случае распределение бюджета рабочего времени сотрудника в течении рабочего дня должно строится по следующей схеме:

– на задачу 2 приоритета – 5 часов;

– на задачу 3 приоритета – 2 часа;

– на задачу 4 приоритета – 1 час.

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

Если в работе находятся несколько небольших задач 2 и 3 приоритетов, включается правило 1 через 2, то есть сначала решаются 2 задачи второго приоритета, а потом 1 задача третьего.

Еще одно правило - при наличии задач 4 приоритета, сотрудник ежедневно должен уделять таким задачам не менее 1 часа в день.

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

Продолжение следует...

Если ваш стаж пребывания в IT-индустрии превышает 15 минут, то мне не нужно говорить вам о том, что мы работаем в быстро меняющемся пространстве.

Сэм Ньюман

По мотивам

Согласно методологии SCRUM на ежедневных летучках (stand-up, daily meetings ) каждый участник команды должен давать короткую отчетность о своей работе по трем вопросам:

1. Что я сделал вчера?

2. Что я планирую сделать сегодня?

3. Какие у меня возникли проблемы?

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

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

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