Введение
В наше время среди разработчиков распространено убеждение, что хорошие программисты значительно лучше плохих программистов. Величина этого "значительно лучше" является предметом яростных дискуссий. Оценку в 10 раз часто называют консервативной.
В данной статье будет показано, что такие утверждения упускают важные детали и, в целом, ошибочны.
На основе исследования, приведённого ниже будет ясно, что:
только половина разницы в затратах на разработку объясняется разницей между разработчиками
вторая половина объясняется разной производительностью одного и того же разработчика на разных заданиях
Эти важные открытия означают следующие вещи:
нормальная изменчивость мешает попыткам измерить производительность. Это оказывает серьёзное влияние на планирование, измерение и оценку улучшений производительности и процесса разработки;
руководители проектов могут только примерно оценить производительность отдельных разработчиков, даже при наличии значительных примеров работы;
эти же самые руководители обладают другими инструментами для улучшения производительности
Исследования по теме
В наше время считается очевидным, что продуктивность программистов варьируется в широких пределах. Стив Макконнел и Роберт Глас сделали обзор следующих исследований: Сакман, Куртис (1981 и 1988), Майерс и Демарко. Обзор показал разницу в личной производительности от 10-и до 28-и раз. Боэм пришёл к выводу о четырёхкратной разнице для команд, а Демарко считает, что команды могут отличаться на столько же, на сколько и разработчики.
Наиболее значительная критика представлена в работе Лутца Пречелта, pdf, который утверждал, что правильнее смотреть на распределение, а не на отношение статистических выбросов.
Но, важнее то, что ни одна известная работа не использовала анализ повторных измерений для отделения статистической разницы в производительности между программистами от нормальной изменчивости самих разработчиков. То есть, по умолчанию предполагается, что производительность разработчика стабильна. Не смотря на это, Кёртис, в своём небольшом исследовании касающемся скорости исправления ошибок выдвинул предположение о значительной вариации на разных задачах.
Перечисленные проблемы предыдущих работ побудили нас провести собственное исследование, чтобы понять истоки продуктивности программистов.
Новое исследование
Чтобы лучше понять продуктивность программистов в данном исследовании использовались данные собранные в ходе преподавания курса "личный процесс разработки ПО" (ЛПР). В данном курсе (1995) мы обучали разработчиков, как измерить личную производительность и реализовать собственный цикл Деминга. В основе курса — стабильность личного рабочего процесса и его измерения. В рамках преподавания курса, мы ежедневно собирали и демонстрировали классу информацию о прогрессе. Таким образом преподаватели могли видеть, как меняется личная производительность на разных заданиях.
Для исследования мы использовали данные из курса ЛПР с практическими упражнениями. Студенты записывали затраченное время, размер и количество дефектов для нескольких программ. Слушатели курса использовали язык и среду программирования по своему вкусу. Для сбора данных, нужно было симулировать полный цикл разработки. Для этого студенты должны были прочитать и понять задачу, реализовать решение и протестировать его с помощью заданного набора тестов. Задания представляли из себя разные вычислительные задачи, не требующие специальных знаний. Трудозатраты варьировались в пределах нескольких часов. Слушатели записывали время потраченное на основные этапы решения задачи: планирование, дизайн, кодирование, тестирование и обзор.
Данное исследование использовало версию курса с десятью упражнениями. Из 3800 разработчиков (2000-2006 гг.) лишь 494 использовали язык C и реализовали все 10 задач. Средний опыт слушателей составил 3,7 лет. Половина имели опыт менее года. Самый опытный имел стаж 36 лет. Производительность тут измеряется как отношение трудозатрат к среднему по группе для конкретной программы. Не имея объективного метода сравнения программ напрямую, эта относительная шкала не показывает абсолютной производительности на всём наборе программ. Но так как данное исследование относится к программистам, а не к программам, такой подход более чем оправдан.
Рис. 1 показывает квартили продуктивности для каждого из 10 заданий. Следует отметить два момента:
Похоже, что некоторые программисты всё-таки лучше других. Если посчитать соотношение лучших к худшим для каждого из задания, то можно увидеть соотношения 55:1 (задание 1) и 21:1 (задание 7). Такой разброс согласуется с результатами представленными в обзоре литературы
Однако если отбросить выбросы, нет свидетельств сильного превосходства одних разработчиков над другими. На диапазоне между 25-ым и 75-ым процентилями равномерность продуктивности просто поражает (в зависимости от задачи разница между третьим и первым квартилем лежит в пределах от 0,6 до 1,25)
Тут въедливый читатель заметит: "Что и требовалось доказать! Некоторые разработчики всегда в числе лучших!" То есть, если какие-то разработчики оказываются в червёртом (верхнем) квартиле на всех задачах, то этих лучших программистов и надо нанимать. Но на практике оказывается, что разработчики постоянно попадают в разные квартили. Это подтверждается вариацией ранга индивидуальной продуктивности.
Рис. 2 показывается разнообразие результатов разных программистов на разных задачах. Эти данные были получены следующим образом: каждому участнику был присвоен ранг от 1-го до 494-х на каждой задаче, в зависимости от того, с какой скоростью он справился с задачей. Для каждого разработчика эти ранги были отражены на графике:
Медиана — синяя линия
-
Доверительный интервал — "усы". Полный диапазон для каждого программиста не отображён на графике.
Рис. 2. Среди 494-х программистов (ось X), имеет место широкий доверительный интервал производительности (ось Y) на разных задачах
На графике заметно несколько важных эффектов:
Безусловно, есть несколько программистов, которые стабильно решают задачи быстрее других (см. диапазоны меньше 50-и) и те, кто стабильно решают задачи медленнее других (см. диапазоны выше 450-и)
Однако, вне этих групп, доверительные интервалы очень широки. Для 90% разработчиков, имеется очень большой разброс времени выполнения отдельных заданий.
Более того, это результат должен предостеречь руководителей от оценки личной производительности программистов, так как эта метрика имеет смысл лишь для небольшой доли сотрудников. Вместо этого, намного полезнее будет изучить причины разброса производительности разработчиков на каждой задаче.
Как бы подчёркивая последний пункт, распределение относительных трудозатрат (таблица 1) показывает, что 90% программистов попадают в группу умеренной производительности. Средний коэффициент вариабельности для отдельных программистов (42%) не сильно меньше общей вариабельности. Фактически 482 из 494-х программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее. Резюмируя, эти показатели демонстрируют, что скорость выполнения заданий определяется случайными неизвестными факторами в той же мере, что и истинной собственной производительностью разработчиков.
Среднее |
Стандартное отклонение |
5% |
25% |
Медиана |
75% |
95% |
|
|---|---|---|---|---|---|---|---|
Относительные трудозатраты |
1,0 |
0,51 |
0,44 |
0,63 |
0,86 |
1,24 |
1,93 |
Таблица 1. Распределение относительной производительности
Последствия для руководителей
Широкие рамки производительности показывают, что даже опытные программисты не сохраняют одинаковую скорость работы на разных заданиях. Нанимать "лучших программистов" не будет настолько эффективным, насколько нам хотелось бы. Тем не менее, мы рекомендуем руководителям следующее:
Принять непредсказуемость даже простых заданий. Декомпозировать всё на маленькие задачи и ориентироваться на тренд, а не на краткосрочные результаты
Собирать много данных для новых инструментов или улучшений процессов. Большинство заданий будут закончены на менее чем на 15% быстрее чем среднее. Естественный разброс может скрыть даже значительные эффекты.
Устанавливать достижимые цели основанные на реалистичных исторических данных о средних и вариациях. Так как некоторые задания потребуют больше времени, чем ожидается, следует начинать большие и критические задания раньше.
Обращать внимание на важность проектирования для контроля сложности и объёма решений.
Поощрять регулярные взаимные обзоры кода. Значительная доля разброса является результатом не оптимального выбора реализации либо исправления сложных ошибок. Дополнительная пара глаз не только заметит альтернативное решение, но и познакомит коллег с другими подходами.
Обеспечить разработчиков тихой рабочей средой, где они могли бы сфокусироваться на решаемых задачах без того, чтобы их отвлекали.
Помогать разработчикам, которые хотят развиваться. Обеспечить возможности для профессионального роста и рабочую среду в которой они могли бы улучшить свои навыки работая за пределами зоны комфорта.
Не концентрироваться на скорости разработки. Например, уменьшение количества дефектов — поддающееся тренировке умение (Ромбах, 2008). Оно не уменьшает производительность, но уменьшает вариативность скорости и уменьшает общую стоимость жизненного цикла.
В целом, несмотря на то, что некоторые программисты лучше и/или быстрее других, важность этого сильно преувеличена. Вместо того, чтобы наклеивать ярлыки, типа "лучший" или "худший", лучшим способом увеличить среднюю производительность будет увеличить производительность каждого. Опыт тут важен, но ограниченно. Следующие рекомендации должны помочь программистам и руководителям собирать данные и повышать производительность: Определите процесс разработки; измеряйте трудозатраты; считайте, классифицируйте и измеряйте дефекты; измеряйте продукт; оценивайте объём продукта и затраты на разработку; делайте обзоры кода по списку; проводите демонстрацию и обзоры проекта
Комментарии (69)
sshikov
27.11.2023 10:59+11На основе исследования, приведённого ниже будет ясно, что:
только половина разницы в затратах на разработку объясняется разницей между разработчиками
вторая половина объясняется разной производительностью одного и того же разработчика на разных заданиях
Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
По сути, все что тут доказали - это то что факторов много, и повышать производительность можно по-разному. Так никто и не утверждал обратного.
А что мерять производительность сложно, и надо учиться делать это лучше - так это тоже достаточно очевидно.
event1 Автор
27.11.2023 10:59+3Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
Миф не в том, что она разная, а в том, что она постоянная. А данная работа как раз и показывает, что она сильно не постоянная.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
Вероятно, это один из факторов непостоянства
sshikov
27.11.2023 10:59+5Все исследования что я видел, основаны на некотором ограниченном измерении. Если мы намеряли, что Вася быстрее Пети в 10 раз - как можно из этого делать вывод, что он и завтра тоже будет быстрее, если при этом задачи изменятся? Сегодня они бежали на 100 метров, а завтра у них марафон.
Не вижу никаких причин такие исследования обобщать так сильно. Но если послезавтра нам снова бежать 100 метров - я таки поставлю Васю.
igor_suhorukov
27.11.2023 10:59Вот так всегда - как бежать, так снова Вася!) Мотивация за его добросовестность.
Ждем когда нейросетки заменят кодирование - стабильно работая без больничных и отпусков.
sshikov
27.11.2023 10:59Не-не. Не бежать - а бежать 100 метров! Это большая разница! Марафон побежит Витя :)
igor_suhorukov
27.11.2023 10:59Хорошо, если Вася будет наблюдать рекорд Вити за кружкой нефильтрованного)
DaneSoul
27.11.2023 10:59Тут скорей вопрос не в том, кто лучше бегает Вася или Петя, а в том, что у Васи замеряли скорость бега, а в реальных задачах надо еще иногда плавать и жать штангу. Соответственно разные спецы топы в разных типах задач и при отборе команды это следует учитывать.
sshikov
27.11.2023 10:59Разумеется. Так я об этом в том числе и говорю - все что у нас есть, это результаты конкретных измерений, согласно которым Вася лучше бегает на 100 метров, чем Петя, причем он в 10 раз быстрее. Если кто-то обобщает это на марафон - разве это проблемы того, кто проводил измерение? Кто-то выяснил, что эти коэффициенты далеко не константы? Спасибо, Кэп, но я лично и так догадывался, что производительность изменчива.
SquareRootOfZero
27.11.2023 10:59+3Насколько я помню, "миф" (уж в кавычках или без), зачастую преподносился в том виде, что существуют некие "хорошие разработчики" и "просто разработчики", и производительность первых в разы (иногда пишут про десятки раз) выше оной вторых, при этом - ключевой пункт - независимо от опыта. Т. е., согласно "мифу", через какой-то относительно небольшой временной промежуток (зачастую фигурировала цифра в пять лет, а минимально, кажется, мне попадалась и в два года... джва года, Карл!) разработчик упирается в некий непреодолимый потолок, только у "хороших разработчиков" он очень сильно выше. Понятно, что если "хорошего разработчика" посадить делать незнакомую задачу на незнакомом языке, провал в производительности будет ожидаем, но он будет за относительно пренебрежимое время преодолен, и опять "хороший разработчик" будет в десятки раз эффективнее "просто разработчиков", даже сидящих за этими задачами на этом языке плотно и давно. Очень модная тема была лет десять назад, уж не знаю, это она с тех пор на нет сошла, или это я перестал читать авторов, которые её разгоняли...
event1 Автор
27.11.2023 10:59+1Именно так. Общественное мнение считает, что у разработчиков есть некоторая собственная производительность, которая сначала растёт, через 5-10 лет упирается в потолок и дальше они с этой же силой работают, пока не выйдут на пенсию. Данная работа как раз и показывает, что подавляющее большинство не имеют такой чётко выраженной производительности и их результаты могут сильно меняться от задачи к задаче
MrCooger
27.11.2023 10:59+1Я лично раз в 5 хуже своих коллег. И тут ничего не поделаешь, кранчи и обучение лишнее только к выгоранию и депрессии привели. Похвала и небольшие повышения зп тоже не вбивают никакие знания и понимания программирования. И на митингах оч сильно видны эти различия с продуктивными коллегами. Так что на личном примере вижу, что х10 не миф.
igor_suhorukov
27.11.2023 10:59+3Вы либо слишком прямолинейный человек, либо "засланный казачок" на этот ресурс. Или разработка программ это не ваше?
Griggon
27.11.2023 10:59+2А какой смысл засылать кого-то с таким посылом?
igor_suhorukov
27.11.2023 10:59Тот же кто и другие аккаунты с меньше 10 комментариями в профиле за все время)
SquareRootOfZero
27.11.2023 10:59+12Оценивать себя по митингам можно только если ты Ленин. Я на митингах обычно вообще "сижу, туплю". Коллеги что-то обсуждают, живо, бойко, вроде, всё по-делу, не воду льют. Меня иногда спросят, типа, а ты что об этом думаешь, я в ответ: "А?... Эээ... А! Согласен! Замечаний и возражений не имею." Да, ценные идеи и дельные мысли мне, обычно, приходят медленно, туго и вразнобой - но тем же бойко мыслящим коллегам они, зачастую, вообще не приходят! Уже после митинга, бывает, посижу, потуплю, похожу, потуплю, схожу, кофе попью, потуплю - вроде, наконец-то что-то начнёт складываться в башке, вопросы начинают возникать - другие какие-то, на митинге, вроде, не обсуждали. Подойду к коллегам: "Слуште, коллеги, а что по-поводу вот этого вот? - Эээмм... чаво?? - (минут пять объясняешь, пока до них дойдёт) - Хмм... а ведь и правда, хороший вопрос. А чо ты на митинге не спросил? - Не пришло в голову, а вы чо не спросили? - Ну, и нам не пришло..." При том что опыт работы и уровень знания предметной области у нас с ними примерно схожий, каких-либо уникальных знаний темы у меня, как правило, нет.
micronull
27.11.2023 10:59+3Такое "дугодумство" часто бывает из-за того что мозг держит в контексте много деталей и склонен на продумывание нюансов.
SquareRootOfZero
27.11.2023 10:59+3Мой, такое чувство, наоборот, ни деталей не держит, ни нюансов не продумывает, а со скрипом пытается составить хоть какую-то общую картину. Ну либо держит эти детали и нюансы где-то в глубине, мне о них не говорит, только уже составленную общую картину показывает.
DaneSoul
27.11.2023 10:59+2Умение видеть общую картину - самый ценный навык.
Надергать деталей и обсуждать частности многие умеют, но если нет понимания общей картины - все в итоге развалится.
VADemon
27.11.2023 10:59на митингах обычно вообще "сижу, туплю". Коллеги что-то обсуждают, живо, бойко, вроде, всё по-делу, не воду льют.
SquareRootOfZero
27.11.2023 10:59О. Всегда как-то скептически относился к креативам этого автора, а тут в первых абзацах прямо узнал себя. Правда, я себя считал не "тупым", а "нестандартно мыслящим", но в последние годы начинает казаться, что это примерно одно и то же. По телефону говорить вообще боюсь панически...
gandjustas
27.11.2023 10:59+3Название статьи не соответствует содержанию.
Лучшие от худших судя по всему могут отличаться в 10 и более раз. Но даже на одной и той же выборки лучшими оказывались разные в разных задачах.
Wesha
27.11.2023 10:59Лучшие от худших судя по всему могут отличаться в 10 и более раз.
Всё уже украдено до Вас. Ещё 12 лет назад.
event1 Автор
27.11.2023 10:59Но даже на одной и той же выборки лучшими оказывались разные в разных задачах.
Об этом и речь. Основной посыл как раз в том и есть, что, вопреки общественному мнению, не существует метрики скорости прибитой к каждому программисту. Для подавляющего большинства скорость варьируется в таких пределах, что невозможно уверенно сказать, кто лучше, а кто хуже
AlexunKo
27.11.2023 10:59+3Как по мне модель куда проще. Ошибка найма множится на ошибки управления и возводится в степень шизофреничного восприятия программистов как серийных механизмов, закупленных на рынке труда, которые могут и в козла отпущения и предсказывать будущее и весьма охотно и эффективно работать на любых задачах, которые ему только кинут в пасть аки кость псине. Вот где-то так и получается хорошие и плохие программисты.
ETman
27.11.2023 10:59+1Интересная статья. Спасибо. Однако у меня есть технические замечания. Выводы, указанные в статье, мне показались не основанными на представленных исследованиях. Возможно, это связано с тем, что статья является переводом. В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
event1 Автор
27.11.2023 10:59В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
Это не было предметом исследования. Главный вывод в том, что для большинства разработчиков скорость варьируется в таких пределах, что невозможно сказать, что один лучше (или хуже) другого. Лично для меня это было открытием
voldemar_d
27.11.2023 10:59+1А что вообще считать за "продуктивность"? Скорость выдачи кода, решающего какую-то задачу? ИМХО, это еще не показатель качественности решения. Можно быстро реализовать какой-то код, но потом может оказаться, что его трудно развивать, добавлять новую функциональность; в нем могут оказаться подводные камни, из-за чего малейшее изменение может привести к куче багов и т.д.
Возможно, кто-то менее продуктивен, зато пишет более качественный код, делает это более аккуратно, с большей ответственностью и т.д. Как это предлагается оценивать?
Dolios
27.11.2023 10:59Коликчество лучше покрывается KPI, чем какчество.
voldemar_d
27.11.2023 10:59Так и я про то же. Можно выдавать много "индусского" кода, который даже как-то работает.
event1 Автор
27.11.2023 10:59конкретно в данном случае речь шла о скорости. В целом я согласен с вами, что продуктивность сложнее, но тут речь шла о модельном исследовании
codecity
27.11.2023 10:59Тут вся заноза в основном свойстве информации операция по копированию практически ничего не стоит. Т.е., грубо говоря, если в вашей голове (или на Stack Overflow и т.д.) уже есть наработки, знания, опыт - то выдать готовое решение труда не составит - вы просто выполняете операцию копирования из головы в редактор кода (пусть и с незначительными изменениями). Если же готового решения нет, в голове пусто, опыта нет - тогда может и в 10 раз и более времени уйти на работу.
konst90
27.11.2023 10:59Если же готового решения нет, в голове пусто, опыта нет - тогда может и в 10 раз и более времени уйти на работу.
Но ведь это и с любыми другими навыками работает.
Условно, если мастер десять лет менял колодки на Солярисе - он может сделать это с закрытыми глазами за полчаса. И если такой же мастер десять лет занимался заменой задней балки на Гранте - то замена колодок вызовет у него затруднения, особенно если нет мануала. А ведь оба десять лет назад выпустились из ПТУ с корочками "Мастер по ремонту ходовой части".
Nialpe
27.11.2023 10:59+1почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
event1 Автор
27.11.2023 10:59Для простых задач метрика скорости вполне оправдана. Дизайн может быть медленнее, но лучше. Но, опять же, для того, чтобы потом было быстрее. В целом, скорость — главная характеристика большинства проектов разработки ПО, так как цена разработки привязана именно ко времени.
gun_dose
27.11.2023 10:59+3Измеряя продуктивность, нужно сразу уточнять, на каком отрезке жизненного цикла ПО она измеряется. У меня много раз было, что условный джун делает задачу, скажем, за час и закрывает её, как решённую. Потом оказывается, что применённое решение работает хорошо только при определённом стечении обстоятельств, да ещё и имеет кучу побочных эффектов. И тогда эту задачу повторно открывают и отдают мне, а я её делаю, к примеру несколько дней. Вот и получается, что джун сделал задачу в десятки раз быстрее меня, вот только за мной её переделывать не пришлось. Также надо иметь в виду, что возврат задач на доработку (в том числе в виде заново открытых багов, когда задача уже на продакшене) негативно влияет на планирование в целом и на общую продуктивность команды, т.к. всё больше ресурсов уходит на фиксы. Это, кстати, довольно типичная картина, когда маленькая команда берётся за слишком сложный проект, не оценив его сложность. Клиент ведётся на обещанную быстроту реализации, но к назначенному сроку получает лишь очень сырую заготовку, а затем всё тонет в бесконечных исправлениях и доработках, что часто заканчивается судами и даже банкротством одной из сторон.
Хотя конечно, если смотреть в разрезе каких-то средних задач, то обычно я их делаю значительно быстрее уловного джуна. То есть, подход оценки продуктивности по количеству затраченного времени при определённых условиях, безусловно, имеет право на жизнь. В то же время, при других условиях, лучше выбрать того разработчика, который будет делать дольше и дороже, но в итоге сделает хорошо.
event1 Автор
27.11.2023 10:59Для этого студенты должны были прочитать и понять задачу, реализовать решение и протестировать его с помощью заданного набора тестов
gun_dose
27.11.2023 10:59+3должны были прочитать и понять задачу
Увы, это так не работает. Если разработчик не понял задачу, то это не потому что он "забыл её понять", а потому что у него недостаточно опыта или способностей. То же самое касается "заданного набора тестов". Иногда оказывается, что набора никакого нет, но это не значит, что в таком случае можно ничего не делать.
sergyalosovetsky
27.11.2023 10:59+1поправьте меня, если я ошибаюсь
в статье автор говорит, что разные разработчики с разной скоростью решают задачи?
и при этом они имеют специализацию в каких-то определенных областях?
мне кажется, ето совершенно очевидно
большой вопрос насчет репрезентативности исследования, есть у меня ощущения, что особо крутые программисты в выборку не попали
POMXARK
27.11.2023 10:59+1Требуя повышения "производительности", вы теряете лояльность сотрудника, особенно, если это не подкрепляется материально. В частности когда были названы реалитичные сроки, а тебе в ответ, а вот Вася сделает это за 2 недели
sv91
27.11.2023 10:59+1Мне вообще интересно, как измеряется скорость работы программиста внутри одной команды. Одно дело, когда работа программиста - это "взял задачу с доски, решил, взял следующую". Но гордиться скоростью решения таких задач.. ну такое. "Смотрите, я винтик в колесе, но не просто винтик, а 10x винтик!"
Другое дело, когда это исследовательская задача. На дизайн, на придумывание интересного алгоритма и т.п. И тут уже появляется взаимодействие с командой. Но если ты единственный 10x программист в команде, то объяснить свое решение займет гораздо больше времени, чем собственно проработка этого решения. И все эти 10x затраченное на решение просто нивелируется, усреднившись к скорости работы команды в целом.
event1 Автор
27.11.2023 10:59Мне вообще интересно, как измеряется скорость работы программиста внутри одной команды
Внутри команды — никак и не надо.
witRoman
27.11.2023 10:59-1Печально признавать, но это все сладкие маркетинговые сказки для фантазеров, которые сами не окунаются в индустрию. На самом деле здесь больше всего работает принцип - максимазации власти(Джеффа Безоса) - нужно заиметь СЕБЕ максимум прав и политик и стараться по макс отдалять от глори-задач коллег-конкурентов, по возможности не давать им никакой инфы, ни доступов, перекидывать на них бессмысленную рутину и топить перфекционизмом и бессмысленными правками, и держать свой авторитет так, чтобы им было трудно возражать. Только так, за счет других, можно выплыть в топ, иначе только один путь - бессмысленно барахтаться в болоте нарастающих обязанностей и понижающихся награждений - топя свои амбиции, мотивацию и таланты. =(
bak
27.11.2023 10:59+2Лучшие от средних отличаются не в 10 раз а примерно в бесконечность. При чем не только среди программистов а в целом среди большинства профессий.
Лучшие хирурги спасают жизни в таких ситуациях, в которых 100 средних не спасут впринципе.
Лучшие адвокаты вытаскивают клиентов из таких передряг, из которых ни один средний не сможет вытащить.
Лучшие программисты закладывают архитертуру и принимают технологические решения, разделяющие успешные проекты от загибающихся под тяжестью багов, тормозов и тех-долга.
event1 Автор
27.11.2023 10:59Вы конечно правы, но это скорее техническое лидерство, чем собственно программирование, как написание кода, о котором идёт речь в статье.
AndreyDmitriev
У меня есть реальный, практический пример из жизни, с прошлой работы.
Заказчик в одной северной заснеженной стране возжелал приобрести у одной европейской компании рентгеновскую систему. Причём систему весьма "кастомизированную", сильно допиленную под нужды производственной линии. У нас в то время программный продукт, которому было больше десяти лет, уверенно достиг стадии "легаси", накопилось какое-то количество техдолга, сформулированным требованиям удовлетворял лишь частично, и было принято решение всё программную часть отдать команде разработчиков в одной жаркой южной стране. Для меня это было облегчение — я на тот момент был перегружен другими проектами, а этот старый продукт поддерживал фактически в одиночку, выполняя роли архитектора, разработчика, тестировщика, техподдержки, и даже время от времени занимаясь документацией. Но заказчику надо как-то работать, и было решено поставить вначале систему с "легаси" продуктом, что б железка совсем уж не простаивала, а потом, за 55 недель (прямо так было прописано в контракте) с нуля написать новую программную часть, сменив по ходу платформу с LabVIEW на С#/WPF, походу реализовав всё, что нужно, что в общем было вполне реально сделать за год. Там особо сложного ничего не было, единственная тонкость, где надо было аккуратно отработать — нехитрая обработка изображений почти в реалтайме, чтобы не получить значительных пенальти в управляемом коде, OpenCV было за глаза достаточно, а WPF даёт куда как больше свободы по сравнению с контролами LabVIEW. Супер-пупер UX дизайнер слетал к заказчику, провёл там несколько дней, но судя по всему мало что понял. Первый звоночек прозвенел, когда менеджмент с места в карьер собрал команду из одиннадцати человек (что было несложно, так как шарписты там выстраиваются в очередь). Я на митингах чуть ли не кричал - не надо так, возьмите трёх-четырёх опытных разрабов, они соберут модульный "скелет"-ядро с правильной, элегантной декомпозицией, и потом постепенно можно будет добавлять новых разработчиков, но нет. Сразу возникли проблемы - одни ждали других, интерфейсы не готовы, тут дедлоки, там состояния гонки и т.д...
Прошёл год (в основном митингов). Прототип был едва готов и нежизнеспособен, всё трещало по швам, команда запросила ещё год(!) на доведение до ума. Заказчик вежливо (а потом и не очень вежливо) интересовался - "ну а где, собственно, результат?" Менеджеры вернулись ко мне. Я посмотрел на ТЗ — фактически надо было добавить в старый проект где-то полтора десятка новых фич, чтобы удовлетворить требованиям. Взяв три недели на доработку, я расчехлил древнюю среду разработки, и добавил часть очевидных, потом полетел за океан и ещё за три недели на месте добавил оставшееся. Поскольку я кодил прямо у заказчика, ежедневно внося изменения и на ходу обкатывая их с операторами, мне не составило большого труда довести всё до состояния, когда на вопрос "что ещё вам нужно?" заказчик сказал — "вот теперь всё работает как надо, у нас нет других пожеланий" и подписал акт приёмки. Я получил благодарность и небольшую премию. Вернувшись, я ехидно заметил, что вот теперь недурственно сравнить продуктивность — 11 человек за 55 недель уже угрохали под шестьсот человеконедель, я же справился за шесть в одиночку, 1:100 в мою пользу, и самое главное — результат достигнут, пользователи довольны. Конечно, у меня была заметная "фора" в виде уже имеющихся наработок, но тем не менее. Ну а система работает до сих пор, уже несколько лет, заказчик в процессе эксплуатации нашёл только один невыловленный баг, был пофиксен за пару дней, затем код был заморожен, поскольку шестинедельный спринт-марафон таки окончательно добил его до состояния "не трогай, а то сломаешь", но всё же. Ну а через пару лет и тот проект на шарпе был доведён до приемлемого состояния (впрочем заказчик решил остаться на старой программе, так ему всё понравилось). Потом один из менеджеров за бокалом пива спросил меня "как же так вышло, что проект редизайна был задержан на много месяцев?". Я ответил ему цитатой из Брукса - "знаешь, вначале он задержался на один день".
vilgeforce
" Прошёл год (в основном митингов) " - вот и ответ ;-) Слушая знакомых айтишников у меня складывается впечатление, что индустрия развивается в направлении "больше митингов, меньше кодинга"
event1 Автор
Ну так у нас же нет ничего важнее "софт-скиллов". Умеет там человек программировать или нет, не так уж и важно. Главное, чтоб не токсик
vilgeforce
Именно так!
werevolff
Ну, знавал я токсиков, которые даже программировали токсично. В смысле, так, чтобы люди, которые будут читать или обслуживать их код, захлебнулись.
panzerfaust
Бесконечные митинги - это как раз про отсутствие софтов. Софты это не про болтовню ради болтовни, а про грамотную болтовню для достижения цели. При наличии софтов команда бы уже пришла пусть к плохонькой, но к рабочей дорожной карте, и приступила бы в реализации. А когда софты тухлые, то каждый сидит в своем пузыре, друг друга никто не слышит - и нет конца бла-бла-бла.
mayorovp
Зависит от цели. Когда цель - быстрее приступить к задаче, то всё именно так как вы написали. А вот когда цель - скрыть отсутствие хард скилов, то все софт скилы направляются именно на растягивание митингов...
panzerfaust
Миром правит не тайная ложа, а явная лажа. Очень сомнительно, что целая группа людей умышленно пытается что-то там скрыть. Гораздо более вероятно, что тупо не умеют договариваться и планировать.
event1 Автор
Группа разработчиков без умения и желания общаться друг с другом просиживает целые дни на совещаниях? Не видел такого.
По моему опыту, желание всё пообсуждать в широком кругу есть только у неуверенных руководителей. Профессиональные разработчики склонны болтать поменьше, а делать побольше. Лучше потом переделать за полчаса, чем лишний час сидеть теоретизировать в широком кругу
AndreyDmitriev
Не, разработчики дисциплинированные и работают, и при этом совещаются строго каждый день, это же аджайл, всё по учебнику. Менеджеры совещаются чуть реже, но обильнее. Скажем, после недели обсуждений решают сделать кастомные контролы, ещё пара недель и UI дизайнер выкатывает решение заменить стрелки инкремента/декремента на плюсики и минусики слева и справа. Свежо, да. Выглядит стендап митинг так: Рамануджан, ты чем занят? Я делаю кнопки инкремента. Ну ОК. Проходит день. Следующий стендап: "я работаю над кнопкой декремента". Я вежливо интересуюсь, чем же она так отличается от инкремента? Скрам мастер ёрзает - технические вопросы мы не обсуждаем. Ну как же - там ведь юзер может натыкать в минус!. "Ну да, а плюсом может натыкать в вечность" - хочу сказать я. Но говорю лишь, что там тоже лимит есть. "Лимиты - это отдельная сториз и следующий спринт". На показе вижу, что нет юнита - этот контрол показывает миллиметры. Но тут проблема - экран настроек не готов. Я его прошу замокать временно это дело, сам он не может, просто ждёт, ну и так далее. На код ревью вижу, что десятичная точка забита в код намертво и торчит как шляпка гвоздя. Вежливо замечаю, что не у всех десятичный разделитель в виде точки, бывает и запятая. "А у нас нет такой сториз, что юзер должен иметь возможность переключить". Нет сториз - нет работы. Серия обсуждений с менеджерами, архитектором и дизайнером и поехали на новый круг сюрреализма.
Radisto
Из искусства превращается в индустрию, а в индустрии подобная хрень уже никого не удивляет. Инженер иной раз работает урывками между написанием отчетов начальству и совещаниями с этим самым начальством, от которых нет толку, потому что это контроль ради контроля, поддержание в начальстве иллюзии того, что оно что-то понимает и на что-то влияет
AndreyDmitriev
О да, я примерно до пятидесятого совещания довольно дотошно вёл дневник проекта (что очень помогло для реалистичной оценки следующих похожих проектов), но мне в общем уже к концу второго спринта стало всё ясно, так что я был полностью готов к "Плану "Б", в виде спасения проекта при помощи допиливания легаси продукта.
shasoftX
Организационная часть важна.
Есть простое правило - не стоит сразу кидаться делать то, что сказал заказчик. Заказчик к вечеру может или передумать или изменить постановку на 180 градусов. А ты уже сделал. И тебе придется сначала всё откатить, а потом исправлять по новой постановке.
Постановка должна устояться :)
dedmagic
https://www.youtube.com/watch?v=W1l6Tpq-5YI
MAXH0
[улиточка - сотрудник месяца.jpg]
ChaosOrganizer
Тогда заказчик должен доплатить за доработку :) Передумать он может в любой момент, хоть к вечеру, хоть через неделю. Прежде чем кидаться делать, нужно согласовать постановки и убедиться, что есть письменные (хотя бы в виде переписки в чате) свидетельства согласия заказчика с ними. Честно сказать, это не всегда помогает, но иногда всё же помогает.
shasoftX
Тут ньанс в том, что заказчик может попросить сделать другую доработку. А чтобы её сделать нужно откатить изменения по текущей. Одно дело просто с git слить старую версию и доработать, совсем другое дело если нужно вручную откатывать все сделанные изменения. И вот тут уже заказчик может быть не готов оплачивать работы по откату.
AndreyDmitriev
Для этого у нас в штате есть должность, которая называется "ведущий системный инженер". Именно он обсуждает изначальные требования. Часто бывает так, что заказчик их вообще строго сформулировать не может — у него есть лишь "видение", как должна работать система, ну а искусство системного инженера — переложить это дело на бумагу в виде строгих сториз "пользователь жамкает вот по этой кнопке и происходит то-то". Если требования начинают меняться — это проблема именно системного инженера. Ну и очевидно, что чем позже по временной линии проекта они меняются, тем дороже стоят. Ну а кто платит за этот праздник — это уже другой вопрос.
Wesha
...и именно от его квалификации зависит, сумеет ли он довести заказчика до нервного срыва!
voldemar_d
ИМХО, это главное. Въезжать в новую задачу - уже непросто. А если она узкоспециализированная - тем более. Если есть человек, который уже ее почти сделал, вряд ли кто-то со стороны, если у него уже не было опыта решения аналогичных задач, быстро с ней справился.
AndreyDmitriev
О нет, тут не совсем этот случай. Во-первых, перед началом проекта я написал полное и очень подробное техзадание, угрохав на это полторы недели. ТЗ было проанализировано, принято, на основе этого были оценены и приняты сроки, 55 недель взялось отнюдь не "с потолка". Во-вторых, существующий продукт уже выступал в качестве рабочего прототипа, не надо было ничего изобретать, а надо было просто сделать тоже самое, только чуть лучше. И в-третьих, в команду были включены инженеры, уже разрабатывавшие софт для рентгеновских систем, им не нужно было объяснять, что такое детектор, калибровка и 16 бит картинка и как её на экране показывать и т.д. Там вся разработка как "по учебнику" шла. Вообще сделать реалистичную оценку сроков в самом начале проекта — это, конечно, непросто, но в данном случае особого давления не было, поскольку система уже кое-как работала на старом продукте. Я научился с годами не профукивать дедлайны, потому что для меня дедлайн выглядит в виде приехавшего крана, который грузит десять-пятнадцать тонн железку на спец грузовик, который отвозит это дело в аэропорт или в порт, а там заказано место на корабле или самолёте. А эа простой конвейера в виде незапущенной вовремя системы — бывает пенальти в виде одного процента стоимости в сутки простоя, а система стоит миллион плюс/минус (и отнюдь не рублей) и вот это вот всё в общем и целом весьма хорошо бодрит и организует.
voldemar_d
Респект. При такой подготовке, действительно, непонятно, откуда взялись такие проблемы с реализацией со стороны других исполнителей. Тотальная лень и нежелание разбираться?
За такое, ИМХО, надо устраивать всем разнос и требовать немаленькую премию.