35
« : 29 Декабря 2009, 16:41:19 »
Как мне кажется, очень часто на практике при разработке ПО не уделяется внимание тому, что разработка ПО - это процесс. А между тем, это подчеркнуто даже в названиях методологий, к примеру, в RUP, "P" это process.
Понимаю, что мое замечание может показаться непонятным и постараюсь прояснить его смысл и почему я вообще отвечаю здесь.
Методология процессного управления, помимо многих очевидных действий, таких как выделение команд, ролей, регламентирования процессов и т.п., (применяемых, кстати, многими и при разработке ПО) также требует вовлечения каждого участника в процесс и мотивированности каждого участника на достижение общего конечного результата.
И здесь я вижу большое различие с тем, как обстоят дела с управлением в нашей индустрии разработки ПО. Сразу оговорюсь, что мои рассуждения касаются «традиционной» модели управления, новых методик типа agile я не знаю, может быть там все по-другому.
Как мне представляется, во главу угла при планировании и организации работ при разработке ПО ставится функциональность (начиная с принципов выделения ролей в команде и кончая, в особо продвинутых случаях, списком функций для каждого). Это приводит к тому, что у рядового участника процесса исчезает понимание того, как его действия влияют на общий конечный результат и он просто начинает выполнять свои "функции" - анализировать, писать код, тестировать и т.п. На мой взгляд, проблем тут возникает много. Скажу о том, что мне представляется важным а) такое отношение к делу отупляет, б) страдает процесс в целом.
Так, при процессном управлении, в случае нехватке ресурсов тестировщиков, аналитик мотивированный на достижение общего результата вполне может самостоятельно выполнить работу тестировщика (естественно, согласовав это с PM-ом).
В случае же «функционального» управления аналитику попросту не придет в голову выполнить работу тестировщика. Или же он может «погнушаться» этим, такое встречается даже чаще.
Подчеркну, что основной смысл моей мысли отнюдь не в том, какое управление в организации. И при процессном управлении могут быть неоптимальные процессы. Проблема залегает глубже - в менталитете каждого участника процесса. Если участник процесса а) осознает (сам осознает, а не потому, что приказали), что его (без)действия напрямую влияют на результат, и б) он на этот результат мотивирован – тогда процесс в целом будет выполняться быстрее и качественнее. А если все участники работают «от сих до сих» - процесс будет идти, но медленно и со скрипом. Яркий пример - государственные учреждения, где вся организация базируется на функциональном делении.
Так вот, резюмирую. Эдуард, мне кажется, что в будущем, возможно, стоит уделить внимание тому, чтобы донести до большинства ваших студентов мысль о том, что каждому из них хорошо бы понимать, как галочки в его локальном «To-Do» связаны с конечной галочкой в общем «To-Do». И что действия каждого, способствующие достижению значимого общего результата – это хорошие действия. Даже если их изначально не было в локальном списке задач.
ps. Само-собой, я не призываю к анархии. Планирование, контроль и управление никто не отменял и не отменит. Так что мое высказывание не стоит воспринимать в духе "каждый сам себе PM и начальник".
Просмотр сообщений
