Scrum

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% ). Вместо ситуации “...теперь мы видим хорошие перспективы” мы честно говорим “... но сейчас мы всё продолбали”.

Источник: https://infostart.ru/public/961655/