У тебя что, папа стекольщик? - Размышления о прозрачности в управлении проектами

Публикация № 961655

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

19
Что понимается под прозрачностью? В общих чертах - когда ход и результаты процесса видны и понятны всем ключевым участникам проекта. 

Scrum - один из модных нынче фреймворков для управления проектами - предлагает управлять проектами при помощи прозрачности, проверки и адаптации (transparency, inspection and adaptation). 
Не буду здесь агитировать за Scrum - многие эксперты склонны считать, что в среде 1С  чистом виде он для управления проектами внедрения неприменим (вот и тема для очередной статьи, кстати). Но поговорю здесь про прозрачность и то, что она дает в управлении проектами независимо от того, работаете ли вы по Водопаду, по Agile, по гибридным подходам, и так далее. 

Зачем нужна прозрачность?

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

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

Чем плохо отсутствие прозрачности?
Люди могут заниматься имитацией бурной деятельности. Иногда подолгу. 
Прозрачность мешает руководству создавать ощущение собственной важности.

Лирическое отступление про любовь (слайдов не будет, не надейтесь).
Я несколько раз встречала серию высказываний про то, что бывает, когда человек действует без любви… Там были, в-частности, такие слова:

Справедливость без любви делает человека жестоким
Ответственность без любви делает человека бесцеремонным
Правда без любви делает человека критиканом
Компетентность без любви делает человека неуступчивым
Власть без любви делает человека тираном

Так вот, перефразируя эти слова хочу сказать: “Контроль без сотрудничества делает отчетность подтасованной”...

Что я имею в виду? Скажем, вот 1С:Технология стандартного внедрения предлагает инструмент “Лист учета рабочего времени” - при помощи которого заказчик может увидеть, сколько рабочего времени исполнитель потратил на работу, и сколько подлежит оплате. Многие применяют подобные инструменты - удобно, логично. Теперь, внимание, вопрос - соответствует ли содержание такого листка действительности? Не знаю, как в вашей практике - но в моей очень часто - нет. Исполнитель старается показать свою работу заказчику в самом выигрышном свете, выдавая результаты, какие должны быть, а не какие есть.  То есть, иногда быстро решенные задачи указываются как долго решаемые. А наоборот, когда Junior разработчик долго бьется над проблемой, указанное в таком листке время может быть больше реального. 
Плохо ли это? Это - данность, мне кажется, сам вопрос о том хорошо это или плохо - не уместен…


Призываю ли я вас не контролировать? Нет. Я вообще никого ни к чему не призываю. И стараюсь избегать слов “я знаю, как вам надо работать”. И заодно, стараюсь избегать людей, которые говорят “я знаю, как надо делать, а всё остальное - глупости”...  Вообще, чем больше я работаю в сфере ИТ-проектов, тем больше убеждаюсь, что универсальных советов не существует, и у каждой организации, у каждой команды - своя история. И вообще, мне чаще всего важнее не что утверждает мой коллега или наставник, а как он это утверждает. Если человек придерживается близких со мной взглядов, но излагает их в стиле “если вы до сих пор этого не понимаете, то вы профнепригодны” - я в меньшей степени готова буду с ним взаимодействовать, чем если он утверждает что-то противоположное, но с оговорками: “мой опыт показывает… у меня сложилось впечатление… я всегда рекомендую…”
Во втором случае возможен диалог, а это - главное.

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

Итак, при каких условиях получится прозрачность? 

 

  • Условие первое. Заинтересованность участников, в первую очередь руководства.
  • Условие второе. Атмосфера сотрудничества. Когда для обеих сторон важна цель - сделать хороший продукт. Когда обе стороны работают в парадигме Win-Win, и заинтересованы в том, чтобы обоим было хорошо, а не в том, чтобы наколоть партнера и раскрутить его на как можно больший результат за как можно меньшие деньги. 
  • Условие третье. Понятные и прозрачные правила игры. Есть доступный всем заинтересованным сторонам бэклог продукта, в котором очевидным образом декомпозированы задачи - то есть всем участникам очевидно, что имеется в виду под тем или иным требованиям. В моей практике, к сожалению, нередко бывали ситуации, когда на старте заказчик, владелец продукта и разработчик понимали под одной и той же размытой формулировкой требованием принципиально разные вещи. В парадигме Agile это нормально, но только для тех требований, которые пока в листе ожидания. А перед тем, как то или иное требование берется в работу, его нужно декомпозировать и разъяснить. Есть формализованные ограничения: например, WIP-лимиты (Work in progress limits) - ограничения на число одновременных задач в работе. Есть регламентированное время демонстрации, ретроспективы. Есть критерии приемки, проговоренные на старте. 
  • Физическая доска - лучше электроннойУсловие четвертое. Использование информационных радиаторов. Английский термин information radiator введен как антоним понятия information refrigerator (“информационный холодильник”) и немного лучше смотрится в английской версии, чем в русской. Но суть от этого не меняется - вместо того, чтобы максимально “запирать” информацию внутри “холодильника” и про большинство вопросов говорить “это вам знать не положено”, мы делаем ее максимально доступной - например, вешаем доску с задачами в проходе, на виду у всех, проводим открытые совещания (на стэндап-совещания в Инфостарте, скажем, иногда набивается пол-комнаты “зрителей”, которые в проектную команду не входят, но им по каким-либо причинам важно отслеживать ход проекта). То есть мы прилагаем усилия, чтобы информация была максимально доступной.
  • Условие пятое. Использование наглядных инструментов, которые легко потрогать (Low Tech High Touch Tools). Не смотря на то, что Agile считается передовой и современной технологией, его адепты призывают применять максимально простые инструменты. Вместо сложных аналитических отчетов, которые непонятны половине участников (например, метод освоенного объема, сложные формулы для расчета рисков и т. п.), предлагается использовать максимально простые и наглядные инструменты. Не смотря на то, что практикующие разработчики Agile могут запрограммировать всё, что угодно, идеальным вариантом доски считается не сложное ПО, а физическая доска со стикерами (про нее красиво писал в статье на Инфостарте Андрей Капитонов "доска, особенно если на ней стикеры зеленого, желтого и оранжевого цветов, напоминает осень... и уборщица по утрам шуршит опавшей листвой, иногда пытаясь вернуть бумажки на доску, отчего ведение проекта приобретает весьма загадочные формы" - лайфхак - приклеивайте бумажки скотчем). Одним из следствий применения простых инструментов является то, что с их использованием труднее обводить друг друга вокруг пальца. Вместо состояния “почти готово” мы видим, что действительно готово на самом деле (одна из моих любимых пословиц - “не так страшны первые 90% работы, как вторые 90% ). Вместо ситуации “...теперь мы видим хорошие перспективы” мы честно говорим “... но сейчас мы всё продолбали”.

 

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

19

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Kindman1980 53 12.12.18 09:16 Сейчас в теме
Асхат Уразбаев в прошлом году говорил что при использовании гибких методологий учет трудозатрат вообще глупость.
Особенно разбивка факта по задачам. План с фактом все равно не сойдется. Если говорить о рядовом сотруднике, то человек может думать либо о решении задачи и тогда он в "потоке", либо о том как затраты правильно отразить.
И еще -когда проект по гибким методологиям, команда кросс-функциональная. Заказчик и подрядчик как правило должны находиться в одном месте. Если они в разных комнатах, либо редко встречаются и сверяют ход работ - то здесь причина недоверия. Грубо говоря ты в любой момент должен быть готов сказать, чем сейчас занимаешься. Опять же на эту тему у ScrumTrek много видео на эту тему.
2. MariaTemchina 577 12.12.18 10:04 Сейчас в теме
(1) Асхат - несомненно умный человек! Не буду с ним спорить. Но по моему опыту, производительность хоть как-то мерить полезно.
Про заказчика и подрядчика в одном месте - хитрый вопрос. По моему опыту, плохи обе крайности. И когда редко встречаются и сверяют ход работы - чаще всего результат не очень устраивает. И когда заинтересованные стороны постоянно пристают с разработчиками с предложениями о дополнениях. Не случайно есть специальная роль владельца продукта, который как раз "берет основной удар" по взаимодействию с заказчиками и пользователями на себя, не мешая разрабочикам работать. Для ответа, чем ты сейчас занимаешься есть специальные мероприятия, в первую очередь - стэндап-совещания и демонстрации.
3. Petr54-ru 69 12.12.18 11:06 Сейчас в теме
Я в свое время управлял маленькими проектами автоматизации HoReCa, на продуктах от компании UCS - R-Keeper и иже с ними. У наших "киперщиков" программистов внедренцев выходило в сутках по 36-38 оплаченных заказчиков часов рабочего времени и никого это тогда не смущало, кроме наших продажников.

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

На автоматизации супермаркетов такого не получалось. Там как все билось один в один.

А самый тупой и в то же время убийственно эффективный инструмент управляемости на больших проектах (из букваря) - это когда все члены проектной команды после каждого рабочего дня отправляют руководителю проекта письменные отчеты о том, что сделано за сегодня и что планируешь сделать за следующий рабочий день. А руководитель проекта еженедельно от оправляет всем причастным отчет о состоянии проекта, о том, что сделали за неделю, и что собираются сделать на следующей неделе.
MariaTemchina; +1 Ответить
4. MariaTemchina 577 12.12.18 14:40 Сейчас в теме
(3)
в сутках по 36-38 оплаченных заказчиков часов рабочего времени
- прекрасная история, спасибо!..
5. starik-2005 1687 12.12.18 15:56 Сейчас в теме
6. capitan 1110 13.12.18 14:55 Сейчас в теме
Мария, все дело в том, что работа творческих людей трудно поддается оценке.
Обычно тут приводят пример (может и байку) про Фарадея
Когда на Гудзоне поставили первую электростанцию, генератор вращался, но не выдавал ток.
А генератор в те времена был один. Т.е. фиаско.
Приехавший Фарадей поставил крестик мелом на крышке и сказал - здесь отмотать столько то витков.
Это было сделано и ток пошел.
Через месяц компания получила счет на 100 долларов (в те времена - очень много).
Удивленное руководство задало вопрос "Почему так дорого? Расшифруйте, плиз".
Ответ: "Крест мелом: 1 доллар, За то, что знал, где поставить: 99"
За свою трудовую деятельность я видел подобные примеры не раз.
Кстати отсюда могут и 36-38 часов рабочего времени получиться - просто человек три задачи делает одновременно.
А объяснить это заказчику - затруднительно, не каждый из нас Фарадей )

Если у вас выполняется Условие второе. Атмосфера сотрудничества - то подробный учет трудозатрат это не самая нужная вещь.
MariaTemchina; +1 Ответить
7. acanta 48 13.12.18 15:15 Сейчас в теме
Расширение сознания: 1 доллар за то что знаешь правильный ответ, 99 - за то как его получить.
8. Rico17 29 15.12.18 01:52 Сейчас в теме
Необходимо уточнить - раскрыть термин "прозрачность".
1. Философская концепция - это когда ничего не мешает иметь адекватную картину происходящего. Независимую от точек зрения участников проекта.
2. В плане понимания - это когда РП понимает интересы и поведение основных участников проекта (себя, разработчика, клиента).
3. В плане учета работы и главное ее ценности для участников - для каждого должна быть своя отчетность. Например, разработчик ведет свои часы, потраченные на выполнение задачи. Менеджер выставляет те часы, которые необходимо выставить клиенту. Клиент может согласовать иное количество часов.
4. Необходимо понимать, что всегда есть надсистема, критерии оценки которой не известны участникам. В том числе и "рычаги" влияния на результаты проекта.
9. Valerych 17.12.18 23:29 Сейчас в теме
Так и не понял из статьи, прозрачность это история про трудозатраты, или не только?

Ну к примеру в условном водопаде есть такие интересные стадии как проектирование и разработка.
Для многих менеджеров проекта это чудесные возможности пропасть с радаров Заказчика
Даже если менеджер проектов не использует ресурсы для других проектов, а честно отрабатывает задачи Заказчикаа, с точки зрения Заказчика эти стадии выглядят как черный ящик.
И вот тут может помочь стратегия прозрачности, когда менеджер проекта намечает и реализует вехи проекта, на которых показывает Заказчику что и на каком свете находится. Эдакая добровольная подотчетность с целью быть понятнее и прозрачнее для Заказчика (ну заодно позитивно для риск-менеджмента, опять же получение обратной связи и т.п.)
10. MariaTemchina 577 18.12.18 11:04 Сейчас в теме
(9)
Так и не понял из статьи, прозрачность это история про трудозатраты, или не только?

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