Разделение обязанностей и ответственности в проекте
20 марта, 2008
Собственно давно в голове крутится тема, решил ее в буквах оформить. Подтолкнул к этому пост в блоге Виктора Ронина.
В каждом проекте есть дилемма разделения и делегирования обязанностей и ответственности. Каждый ее решает по-своему, а часто и не заморачиваются такими “мелочами” - пилить надо, пилу точить потом будем.
Посмотрим к чему это приводит.
Банальная неразбериха. Проект начинает тормозить практически сразу, это так называемая скрытая фаза. Наиболее точно характеризует ситуация “до дедлайна далеко, еще разберемся”.
Когда работа в проекте стопорится, человека, который возьмется спасать положение, нет и найти его в такой ситуации очень сложно. Потому что не каждый психологически готов кинуться сразу в огонь. Проект скатывается вниз все с большей скоростью. Дальше включите фантазию.
Появление стрелочников. Когда жареный петух уже близко, активизируются защитные механизмы человека, чтоб в белом быть.
Лечение только одно - формализовывать. Других эффективных способов я не вижу, остальные зависят от людей. Здесь главное соблюсти баланс между бумагомаранием и эффективным разделением обязанностей. И ответственности.
Ответственность. Часто наблюдаю ситуацию, когда обязанности разделили, а ответсвенность нет. В итоге вроде бы и человек есть, вот только кто контролировать будет? Еще веселее ситуация становится когда обязанности делегируются, при этом забывают оговорить ответственного. Когда доходит до разбора полетов, ответственным вдруг становится тот, кому делегировали, а исполнитель думает иначе. По моему мнению ответственность надо оговаривать в любом случае, даже самом очевидном - “если что-то можно понять не правильно, то обязательно поймут неправильно”.
Есть несколько вараинтов, которые, кстати, можно совмещать.
Общее для всех - пул обязанностей и ответственности. Неважно, какого размера проект, хоть 2, хоть 300 человек, набор обязанностей везде одинаковый. Объем разный.
план А). Регламент проекта. В нем оговорить, что кому отходит из пула. Либо персонально, либо определить роли в проекте и назначать пул по ролям. В этом случае потребуется еще документ соответствия ролей конкретным людям.
план Б.) Больше подходит для Agile подходов. Обязанности и ответственности написать на листочках/карточках с магнитами. На доске выделить каждому члену команды место, куда собственно все набранные карточки и крепятся. Преимуществ несколько:
- всегда на виду - доску не получится задвинуть в темный угол комнаты 
- забыть свои обязанности просто нереально - следует из предыдущего пункта;
- легко поддерживать в актуальном состоянии - намного проще перекинуть магнит в соседнюю колонку, чем перелопачивать и распространять документ;
- не накладывается стереотип “документ - бюрократия и бумагомарание”, а часто именно это и вызывает стойкое отвращение к “бумажкам” у людей, особенно у разработчиков.
план С.) Ваш вариант. Велкам в коменты
Loading ...15 комментариев на “Разделение обязанностей и ответственности в проекте”
Мое мнение:
Вы должны войти прежде чем комментировать.
марта 20, 2008 в 17:21
Согласен.
Готов дать тебе попрактиковаться во втором способе на следующем же проекте (либо на любом из текущих).
марта 20, 2008 в 17:24
С удовольствием, но всему свое время
Подожду нового, так сказать “С чистого листа”.
марта 21, 2008 в 10:43
единственный минус, который вижу во втором пункте - досок на всех не хватит
а если хватит, то учитывая наше количество проектов - ими будет заставлен весь офис :))
марта 21, 2008 в 19:14
Лерика, скажи а как сложно забабахать виртуальную доску? На любой технологии.
марта 24, 2008 в 17:23
Виртуальная доска нонсен, теряется принцип “- всегда на виду - доску не получится задвинуть в темный угол комнаты”
Можно неделями не заходить на виртуальную доску.
марта 24, 2008 в 17:27
Согласен. Есть у нас уже одна “виртуальная доска”
Многие наши проекты и без досок обойдутся нормально, здесь уже калибр выбирать надо.
марта 24, 2008 в 17:42
To Shagrat:
На мой взгляд основная идей доски — не то чтобы всегда на виду было — а то чтобы 1) всегда глянуть можно было если вопрос появился. 2) Чтобы ничего нельзя было забыть.
А на счет не заходить неделями — человек такое животное, что без проблем привыкает за пару дней не замечать объявление на входной двери — так что и реальную доску перестанет замечать и без темных углов, если вовремя носом тыкать не будут, либо если не будет лично заинтересован в позитивных ее сторонах.
марта 24, 2008 в 17:45
Ну все животные разные, на меня допустим реальные предметы производят гораздо большее впечатление чем виртуальные. Вот к примеру с нашим сотрудником Х, который недавно покинул нашу компанию, если бы я в патницу вечером не увидел напечатанный листок (ну или когда там) то так бы и не узнал, или просто проигнорировал как лишнюю информацию.
Реальная вещь, она воспринимается совсем подругому, её можно потыркать, с неё прикольно снимать магнитик когда выполнил задание. Ты чуствуеш в руках магнитик как трофей, а не тыркаеш в кнопку.
марта 24, 2008 в 17:47
Я не спорю, что реальная доска гораздо лучше, но и виртуальной вполне можно добиться соновной цели. (хоть и не так эффективно)
марта 24, 2008 в 17:48
Черд, походу холивар как то быстро закончился:((
июля 23, 2008 в 12:38
Вообщето, все зависит от человека и от руководства. Не даром же есть тимлидер-> руководитель проекта->проект менеджер. При нормальной организации и достаточном опыте все получится как надо, а доски,документы и др. подходы(которых великое множество) выбираются уже теми кто в случае краха получит по башне. Кстати по поводу Agile подхода явно неверное представление
там доски не нужны, и всплыл этот подход только после появления Ruby on Rails который и позволяет красиво его реализовать, чего нельзя сказать о др. языках.
Кстати советую познакомится с трудами такого человека как Ашманов, там он ясно расставляет точки над тем, кто и за что отвечает.
июля 23, 2008 в 13:20
Похоливарим?
Они настолько круты, что справляются с проектом при меняющейся команде из 6-7 человек без единого документа?
>При нормальной организации и достаточном опыте все
>получится как надо, а доски,документы и др. подходы
>(которых великое множество) выбираются уже теми кто
>в случае краха получит по башне
Интересно, а чем пользуются настоящие ковбо…ну те которые в первой части цитаты?
Цель таких вот досок и документов - это прежде всего для разграничения сфер влияния и ответсвенности, иначе получится настоящая каша: одним участком занимаются сразу несколько человек, а другим никто. И да, когда не прописана персональная ответственность то причину краха не найдешь, удобно для избегания заслуженного подзатыльника
Да вы что?
Можно поподробнее про практику War room и RoR,я что-то упустил этот момент? Кто-то из нас сильно заблуждается…
Ашманова читал, да, можно пдробнее которое из его произведений? Пузырь?
Можете ознакомится со скрамом и обратить внимание на дату его офицального выхода в свет.
Кстати, следующие посты будут именно о нем.
июля 23, 2008 в 13:47
Вов,ты вроде упустил вторую часть процетированного участка
>(которых великое множество) выбираются уже теми кто
>в случае краха получит по башне
Подход выбирается теми кто несёт на себе ответственность. И где тыт тут увидел про анархическое управление проектами?
>Да вы что? Можно поподробнее про практику War room и RoR,я что-то упустил этот момент? Кто-то из нас сильно заблуждается…
Кстати а тут ты про что? Про Agile и RoR?
июля 24, 2008 в 14:46
Значит мы друг друга неправильно поняли
с такой формулировкой я согласен.
>Кстати а тут ты про что? Про Agile и RoR?
Я про вот это:
>Кстати по поводу Agile подхода явно неверное представление там доски не нужны, и всплыл этот подход только после появления Ruby on Rails который и позволяет красиво его реализовать.
Можешь подробнее про связь РоРа и Аджайл?
июля 24, 2008 в 17:29
Без проблем. Начнем с того,что Аджайл всплыл после появления рельсов, так как у них он стал одним из основных принципов. А благодаря бешеной популярности рельсов, этот подхода стали активнее использовать и пиарить.
Достаточно прочесть книгу создателя рельсов (или любую др), что бы увидеть как он видел Agile и RoR.
Пример :
Открываем книгу и видим… что интерфейс и архитектура бд грубо прикидуются на бумаге и сразу начинается разработка, идет тесное общение с клиентом или его представителем, каждый день или даже несколько раз в день клиент видит результаты, результаты сразу обсуждаются и обговаривается план дальнейших действий.
Сделал шаг- показал и обсудит.
Команда 1-3 человека для разработки проекта (1 рельсовик может сделать за месяц то,что др. например: пхп-шники пятером будут месяц делать).
В итоге мы получаем то,чего хочет клиент в кротчайшие сроки без недорозумений и недопонимания + с экономией человеко-ресурсов. Кстаи в идеале из цепи - программист -клиен выбрасуется несколько звеньев (прожект менеджер, руководитель проекта и тимлид).Но это в идеале, при поточном выпуске проектов, руководящее звено должно быть.