воскресенье, 23 февраля 2014 г.

[prog.management] В качестве иллюстрации ко вчерашней теме про выходцев из больших софтверных компаний

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

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

Слова-то все красивые и умные. Да только по факту в регламенте производства ПО такие архиважные вещи, как проектирование, планирование, учет результатов не включены в число "основных производственных активностей". Зато галочка о том, что документ написан и утвержден проставлена. И создано обширное поле для написания и утверждения кучи других регламентов.

Процессы с большой буквы "ПИ" рулят со страшной силой.

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


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

Отправить комментарий