Есть такая шутка:
1. Программист пишет код, который, по его мнению, не содержит ошибок.
2. Тестирование программного обеспечения находит 20 ошибок.
3. Программист исправляет 10 ошибок и сообщает команде тестировщиков, что остальные 10 — не ошибки.
4. Команда тестировщиков обнаруживает, что 5 из исправлений вообще не работают, и одновременно находит 15 новых ошибок.
5. Повторите шаги 3 и 4 три раза.
6. Из-за рыночного давления и чтобы уложиться в изначально установленный чрезмерно оптимистичный график выпуска, продукт наконец поступил в продажу.
7. Пользователи находят 137 новых ошибок.
8. Программиста, который уже получил бонус за проект, нигде не найти.
9. Недавно сформированная команда проекта исправляет почти все 137 багов, но затем находит 456 новых багов.
10. Изначальный программист отправляет открытку с Фиджи тестовой команде, которая страдает от невыплаты зарплаты. Вся тестовая команда увольняется в полном составе.
11. Компания подвергается враждебному поглощению со стороны конкурента. На момент поглощения окончательная версия программного обеспечения содержит 783 бага.
12. Новый генеральный директор вступает в должность. Компания нанимает нового программиста, чтобы переписать программное обеспечение.
13. Программист пишет код, который он считает свободным от ошибок.
По-моему, если такая компания действительно существует, то не обанкротиться было бы медвежьей услугой для людей.
Эта шутка начинается с программиста, заканчивается программистом и обвиняет программистов от начала до конца. Но я хочу сказать, что это целиком провал менеджеров — на протяжении всего процесса вообще не видно никакой управленческой работы. Такие менеджеры не только невежественны и некомпетентны, но и бесстыдны — они перекладывают ответственность за собственную неудачу на программистов.
1. Что даёт программисту право доказывать, что в его коде нет багов? Есть ли тест-кейсы? Проводится ли код-ревью? На этом этапе управление отсутствует.
2. После того как тестирование выявило баги, велось ли какое-либо управление багами? Было ли отслеживание? На этом этапе управление отсутствует.
3. Что доказывает, что программист действительно исправил те 10 багов? И почему остальные 10 — не баги? Определяется ли стандарт оценки багов со слов программиста? На этом этапе управление отсутствует.
4. Понёс ли кто-нибудь ответственность за те 5 исправлений багов, которые не сработали? Добавление новых багов неизбежно в процессе внесения изменений, но при наличии эффективного механизма модульного тестирования эту ситуацию можно было бы значительно уменьшить. На этом этапе управление отсутствует.
5. Итерация — это нормально, но проблемы расходятся, а не сходятся, что показывает отсутствие эффективного управленческого контроля. На этом этапе управление отсутствует.
6. И чрезмерно оптимистичный график, и невыполнимый срок демонстрируют невежество и некомпетентность менеджера. Выпускать продукт силой в таких обстоятельствах — не что иное, как «невежда не ведает страха».
7. Это безответственно по отношению к пользователям, и наибольшая ответственность лежит на менеджере.
8. То, что он способен раздавать проектные премии в таких обстоятельствах, лишь показывает, что этот менеджер не просто глуп.
9. В управленческой работе не произошло никаких улучшений, и проблемы по-прежнему находятся в состоянии расходящейся итерации. Управление по-прежнему отсутствует.
10. Невыплата заработной платы отделу тестирования отражает пренебрежение менеджера управлением качеством и полное невежество в управлении человеческими ресурсами.
11. Два слова для приобретённой компании: поделом вам. Два слова для компании-приобретателя: слепцы.
12. Ясно, что новый менеджер и прежний менеджер стоят друг друга — ни один из них не осознаёт корень проблемы. Впрочем, только такой менеджер и мог принять решение о приобретении такой компании.
13. Повторение истории неизбежно.
Для нормального предприятия или проекта его функционирование должно идти по восходящему циклу. Работа, гарантирующая такое функционирование, — это управление. А основное содержание управления — контроль, включая контроль темпа цикла — не слишком быстро и не слишком медленно; контроль направления развития — только вверх, никогда вниз; и контроль стабильности работы — без резких взлётов и падений, без сборов и роспусков по прихоти.
И ничего из этого не видно в этом примере.
В примере из этой шутки всё определяется разработкой, что прежде всего является ошибкой направления. Продукт служит пользователям, поэтому, конечно, он должен определяться пользователями и рынком, а направление работы в конечном итоге должно выбираться с учётом собственных возможностей. Эта ошибка отражает, что менеджер не очень хорошо понимает то, чем управляет, поэтому он может лишь зависеть от программистов, которые понимают это лучше, — а на самом деле, кроме технологий, они понимают не так уж намного больше.
Если менеджер не понимает то, чем управляет, он не может хорошо этим управлять.
Это не вызывает сомнений, однако отечественная софтверная индустрия, кажется, всегда не желает в это верить. Одна из самых глубоко укоренившихся в китайской софтверной индустрии ложных установок такова: менеджеру достаточно понимать управление, а не технологии.
На самом деле это просто выдумано теми невежественными, некомпетентными и бессовестными менеджерами, чтобы выманивать деньги. Те, кто в это верит, неизбежно заплатят за это деньгами.
Во-вторых, управление качеством. Базовый здравый смысл в управлении качеством подсказывает нам, что перед завершением каждого цикла самая важная задача — подвести итоги и улучшить. Только так мы можем обеспечить, чтобы циклическая работа развивалась вверх, а не выходила из-под контроля и не шла вниз. Только при эффективном управлении качеством можно гарантировать, что процесс итераций сходится и в конечном итоге достигает своей цели. Но в этом примере эта часть явно отсутствует — хотя есть отдел тестирования, его роль — лишь этап контроля качества в управлении качеством; управленческая часть по-прежнему отсутствует.
Затем следует управление человеческими ресурсами. Разработка программного обеспечения — трудоёмкая работа; хотя это умственный труд, это в равной мере означает, что человеческий фактор занимает в ней решающее положение. В примере программист, не завершивший исправление ошибок, получил премию за проект, а столь же усердно работавшие тестировщики были лишены заработной платы. Это не только показывает непонимание менеджером их работы и его пренебрежение управлением качеством, но и говорит о том, что он совершенно неспособен управлять людьми. Это акт убийства команды — убить команду гораздо легче, чем создать её.
Наконец, этот несостоявшийся менеджер превратил свой опыт в эту шутку, позволив всем увидеть, как сильно его обидели программисты, и демонизируя программистов как группу лжецов. Но любой, кто обладает хотя бы небольшими знаниями в области управления, может при простом анализе увидеть, что только невежество и некомпетентность этого человека привели его к текущему положению, а его поведение, связанное с перекладыванием вины на других, лишь дополнительно показывает его бесстыдство. Если менеджеры на высоких должностях даже уклоняются от ответственности, которую должны нести, на что ещё они годны?
Источник: http://blog.csdn.net/raptor/article/details/727299