The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В Agile Manifesto содержится двенадцать принципов. Пятый принцип гласит: “Стройте проекты вокруг мотивированных людей. Предоставьте им необходимую среду и поддержку, и доверьте выполнение работы им.” Я не согласен. Категорически. Эта формула предполагает двоичное отношение к людям: они либо мотивированы и доверяются, либо… что? Им нужно уволить? Это мышление очень типично, судя по моим наблюдениям, и приводит к плохому управлению и неудачам проектов. Вместо этого, наше управление людьми должно быть более итеративным и намного менее жестким.
Всего несколько дней назад я опубликовал цитату из своей последней книги по программной инженерии, Code Ahead, в Instagram. У меня появился интересный и очень типичный ответ от одного из моих читателей (немного отшлифованный):
Это то, что я слышу практически всегда, когда начинаю говорить о вознаграждениях и наказаниях в команде разработчиков программного обеспечения. Я слышу, что это унизительно и программистов никогда не следует наказывать. Вместо этого, как предложил Самир, их следует увольнять, когда они допускают непростительную ошибку. Таким образом, мы либо полностью доверяем им, либо, когда происходит ошибка, … увольняем чертовского негодяя, он ведь был бесполезен!
Ну, может быть, это часть человеческой природы: сначала мы любим, потом ненавидим, и чем сильнее мы любим, тем сильнее мы ненавидим. Но что эти эмоции имеют общего с профессиональным управлением проектами?
Как предложил Уильям Эдвардс Деминг много лет назад, хорошее управление всегда основано на простом цикле Планирование-Действие-Проверка-Корректировка. Независимо от того, что и кого мы управляем, мы должны спланировать сначала, позволить себе и нашим людям выполнить работу, затем проверить, как выглядят результаты, сравнить их с нашими планами, и, наконец, действовать в соответствии с результатами, корректируя планы. Затем мы возвращаемся к части планирования, и цикл начинается заново:
Мы все знаем, что именно так должно разрабатываться программное обеспечение. Много лет назад мы все поняли, что модель Каскадная модель, где все планировалось заранее и затем реализовывалось в соответствии с планами, которые не менялись в процессе проекта, была плохой идеей. Намного лучшей идеей является поэтапная поставка программного обеспечения с внесением изменений в планы и спецификации после каждой итерации. Это гарантирует более высокое качество, более быструю реакцию на ошибки и гораздо лучшую предсказуемость. Это очевидно, верно?
Почему мы не делаем то же самое с людьми? Почему мы мотивируем их заранее, а затем доверяем им… пока они не оказываются полностью ненадежными? Не можем ли мы регулярно проверять их производительность и соответствующим образом корректировать наше доверие? Почему они либо “великолепны” для нас, либо “бесполезны”? Почему мы не можем оценивать их после каждой итерации в зависимости от ошибок и достижений, которые они совершают?
Давайте посмотрим, как формула, которую предлагает Agile, может быть применена к непрерывному циклу ПДКА.
Доверяйте им и они выполнят работу.
Check: —
Act: —
Кажется, что отсутствуют два важных элемента. Мы не проверяем, можно ли им всё ещё доверять, остаются ли у них мотивация и интерес к выполнению работы, а также необходимость замены некоторых из них.
Почему так? Чего мы боимся?
Кроме того, почему программисты считают унизительным, когда их результаты регулярно проверяют и применяют микро-награды и штрафы, тогда как одна “непростительная” ошибка может привести к увольнению, и это им кажется вполне нормальным?
Потому что их менеджеры слабы и глупы, в большинстве случаев. Они просто не знают, как постепенно поощрять и наказывать программистов. Они не знают, как измерять прогресс людей постепенно. Их контрольные средства основаны на вине и страхе: они объединяют программистов, мотивируют их, а затем заставляют их бояться совершить непростительную ошибку.
Точно неизвестно, какая именно ошибка это, это личное решение менеджера. Это может быть сломанный модульный тест, пропущенная встреча, грубое письмо или питье в офисе. Масштаб очень широкий, и никто не знает, на какой стадии программист будет уволен. Даже менеджер не может объяснить это. Решение в большинстве случаев эмоциональное и личное.
Вы знаете, что очень типичной ошибкой в управлении объемом является отношение к большим задачам по правилу 0/100 готовности: они либо “даже не начаты”, либо “полностью завершены”, и ничего посередине. Это можно делать с небольшими задачами, но никогда с большими, потому что это приведет к потере контроля и гораздо большему риску более дорогостоящих неудач. Вы должны разбить свой объем на меньшие части, а затем применить правило 0/100.
То же самое верно и для людей. Вы не можете доверять им 0/100: либо вы полностью доверяете им, либо увольняете. Это слишком рискованно. Вам нужно разложить их надежность и мотивацию на меньшие части и постепенно достигать удовлетворения и разочарования. Как это сделать? С помощью микро-бонусов и микро-штрафов.
How to not hire a bad programmer? #management
— Yegor Bugayenko (@yegor256) June 16, 2019
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:09
