Сколько должно быть уровней управления

[@Chmyaf]

Жаль что с четвёртым пунктом почти везде беда. Захотели люди тишины ночью. Чтобы спать. И сделать так, чтобы те кто спать мешают несли за это ответственность (бабушки, конечно, хотели чтобы она была уголовной). Скрипя зубами и подтягивая пояса выделили денег на работу законодательного собрания. И получили точный список ночных дел за которые наказывают. И пункт, делающий этот список бесконечным: «иные действия». Т.е. по букве закона: тишину нарушать нельзя никак. Мужчинам всё-таки нельзя храпеть, женщинам — стонать, котам — топать, детям — кричать во сне при болезни. Конечно если эти граждане не занимаются деятельностью «при отправлении ими религиозных культов в рамках канонических требований соответствующих конфессий».
И если я правильно понимаю, то во славу давно забытых богов барана ночью можно зарезать (с песнями и танцами). А вот барану при этом мекать нельзя.

[@craft_brother]

Критерии оценки — результат переговоров руководителя и исполнителя. Ни один уважающий себя менеджер не подпишется под нереальными сроками/трудозатратами. Если Вы, конечно, об этом.

[@Chmyaf]

Да, об этом.
А кем должна проводиться проверка контроля качества? Выноситься в отдельный проект или как?

[@craft_brother]

У меня видимо немного другая картина мира ;) Что такое «проверка контроля качества»?

[@Chmyaf]

К примеру кто должен определять что выбранная для решения библиотека полностью подходит для использования?
Т.е. к примеру поставили задачу — взять что-нибудь для работы с soap и сделать плюшку. Разработчик взял библиотеку, сделал плюшку. После этого поставили задачу добавить ws-security, а этого выбранная библиотека не умеет.
По моему мнению, это всё должно продумываться архитектором, который ставит задачи руководителям направлений, которые в свою очередь раздают задачи по отделам. Но в данном случае выходит больше одного уровня в иерархии проекта, что в целом не есть хорошо?
Или я всё не так понимаю?

[@craft_brother]

Вы абсолютно правы. Это зона ответственности системного архитектора. См. пункт 2. Но, ИМХО, он не руководит разработкой ИС, а проектирует ее.

[@ncix]

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

Задачей архитектора является придумать такую архитектуру, чтобы она с одной стороны удовлетворяла текущим требованиям, а с другой была бы достаточно декомпозирована, чтобы можно было выбрасывать и переделывать любые участки системы с минимальным ущербом для других участков.
Обычно говорят о «гибкости» и расширяемости. Но, по большому счету, нужна полная переделываемость. Не должно быть точек принятия решений, требующих сделать выбор раз и навсегда.

[@Chmyaf]

Т.е. unix-way, если я правильно понимаю — набор небольших кубиков, каждый из которых делает свою работу хорошо и может быть при необходимости заменён аналогичным с недостающим функционалом, вместо одной большой собранной в монолит системы.
В целом то, что и предлагается в статье — куча проектов, каждый из которых, при грамотной проектировке, может быть убран/заменён или добавлен новый?

[@craft_brother]

Про современную архитектуру ПО от Мартина Фаулера и его коллеги Джеймса Льюиса. Рекомендую.

[@ServPonomarev]

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

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

Вы вообще к управлению отношение когда-либо имели?

[@craft_brother]

Иерархия работ != иерархия управления.

[@ncix]

4.Установлены измеримые критерии оценки результата: что такое хорошо и что такое плохо.

И эти критерии так или иначе привязаны к системе мотивации персонала, верно? И с ними есть одна проблема — измеряя эти критерии вы стимулируете персонал улучшать именно эти критерии, что однако не приводит к достижению общей цели.

Пример из жизни. Программистов решили мотивировать скоростью выполнения своих задач. Выполняешь быстрее оговоренного срока — получаешь + к премии, выполняешь дольше — не получаешь. И, следуя этим нехитрым правилам, программисты начали с одной стороны давить на руководителя, чтобы им растягивали сроки, а с другой — наотрез отказывались что-то доделывать по-мелочи без регистрации новой задачи. И в итоге появляются в трекере задачи «Добавить двоеточие к лэйблу» или «Увеличить форму по горизонтали на 1 пиксель». Со своей оценкой времени, и воркфлоу. Программисты довольны, делают 110-120% производительности, а проект буксует в бюрократических согласованиях сроков крошечных задач.

[@Chmyaf]

Согласен. Аналогично с тех.поддержкой: пообещали клиентам ответ в течении часа. Ближе к концу часа клиенту отправлялся ответ в стиле «мы работаем над этим». В итоге работы по отпискам добавилось, сроки полных ответов остались такими же, а руководство компании какое-то время пребывало в уверенности, что компания стала работать лучше.

[@craft_brother]

Индивидуальные KPI — зло. Согласен, что измеряем, то и получаем. Показатели устанавливаются на пакет работ, которые выполняет, как правило небольшая команда под руководством тимлида. Пример пакет — разработать 100 форм регламентной отчетности. Команда: аналитик, тимлид, два программиста, два тестировщика. Как-то, так.

[@Mithgol]

Материал http://t.co/TkbljqaBcJ позволяет предполагать: #вертикальВласти (как политическая идея) основана на математике из доклада Арнольда.

— Mithgol (@FidonetRunes) 19 августа 2015