Comments 75
У меня есть реальный, практический пример из жизни, с прошлой работы.
Заказчик в одной северной заснеженной стране возжелал приобрести у одной европейской компании рентгеновскую систему. Причём систему весьма "кастомизированную", сильно допиленную под нужды производственной линии. У нас в то время программный продукт, которому было больше десяти лет, уверенно достиг стадии "легаси", накопилось какое-то количество техдолга, сформулированным требованиям удовлетворял лишь частично, и было принято решение всё программную часть отдать команде разработчиков в одной жаркой южной стране. Для меня это было облегчение — я на тот момент был перегружен другими проектами, а этот старый продукт поддерживал фактически в одиночку, выполняя роли архитектора, разработчика, тестировщика, техподдержки, и даже время от времени занимаясь документацией. Но заказчику надо как-то работать, и было решено поставить вначале систему с "легаси" продуктом, что б железка совсем уж не простаивала, а потом, за 55 недель (прямо так было прописано в контракте) с нуля написать новую программную часть, сменив по ходу платформу с LabVIEW на С#/WPF, походу реализовав всё, что нужно, что в общем было вполне реально сделать за год. Там особо сложного ничего не было, единственная тонкость, где надо было аккуратно отработать — нехитрая обработка изображений почти в реалтайме, чтобы не получить значительных пенальти в управляемом коде, OpenCV было за глаза достаточно, а WPF даёт куда как больше свободы по сравнению с контролами LabVIEW. Супер-пупер UX дизайнер слетал к заказчику, провёл там несколько дней, но судя по всему мало что понял. Первый звоночек прозвенел, когда менеджмент с места в карьер собрал команду из одиннадцати человек (что было несложно, так как шарписты там выстраиваются в очередь). Я на митингах чуть ли не кричал - не надо так, возьмите трёх-четырёх опытных разрабов, они соберут модульный "скелет"-ядро с правильной, элегантной декомпозицией, и потом постепенно можно будет добавлять новых разработчиков, но нет. Сразу возникли проблемы - одни ждали других, интерфейсы не готовы, тут дедлоки, там состояния гонки и т.д...
Прошёл год (в основном митингов). Прототип был едва готов и нежизнеспособен, всё трещало по швам, команда запросила ещё год(!) на доведение до ума. Заказчик вежливо (а потом и не очень вежливо) интересовался - "ну а где, собственно, результат?" Менеджеры вернулись ко мне. Я посмотрел на ТЗ — фактически надо было добавить в старый проект где-то полтора десятка новых фич, чтобы удовлетворить требованиям. Взяв три недели на доработку, я расчехлил древнюю среду разработки, и добавил часть очевидных, потом полетел за океан и ещё за три недели на месте добавил оставшееся. Поскольку я кодил прямо у заказчика, ежедневно внося изменения и на ходу обкатывая их с операторами, мне не составило большого труда довести всё до состояния, когда на вопрос "что ещё вам нужно?" заказчик сказал — "вот теперь всё работает как надо, у нас нет других пожеланий" и подписал акт приёмки. Я получил благодарность и небольшую премию. Вернувшись, я ехидно заметил, что вот теперь недурственно сравнить продуктивность — 11 человек за 55 недель уже угрохали под шестьсот человеконедель, я же справился за шесть в одиночку, 1:100 в мою пользу, и самое главное — результат достигнут, пользователи довольны. Конечно, у меня была заметная "фора" в виде уже имеющихся наработок, но тем не менее. Ну а система работает до сих пор, уже несколько лет, заказчик в процессе эксплуатации нашёл только один невыловленный баг, был пофиксен за пару дней, затем код был заморожен, поскольку шестинедельный спринт-марафон таки окончательно добил его до состояния "не трогай, а то сломаешь", но всё же. Ну а через пару лет и тот проект на шарпе был доведён до приемлемого состояния (впрочем заказчик решил остаться на старой программе, так ему всё понравилось). Потом один из менеджеров за бокалом пива спросил меня "как же так вышло, что проект редизайна был задержан на много месяцев?". Я ответил ему цитатой из Брукса - "знаешь, вначале он задержался на один день".
" Прошёл год (в основном митингов) " - вот и ответ ;-) Слушая знакомых айтишников у меня складывается впечатление, что индустрия развивается в направлении "больше митингов, меньше кодинга"
Слушая знакомых айтишников у меня складывается впечатление, что индустрия развивается в направлении "больше митингов, меньше кодинга"
Ну так у нас же нет ничего важнее "софт-скиллов". Умеет там человек программировать или нет, не так уж и важно. Главное, чтоб не токсик
Именно так!
Ну, знавал я токсиков, которые даже программировали токсично. В смысле, так, чтобы люди, которые будут читать или обслуживать их код, захлебнулись.
Бесконечные митинги - это как раз про отсутствие софтов. Софты это не про болтовню ради болтовни, а про грамотную болтовню для достижения цели. При наличии софтов команда бы уже пришла пусть к плохонькой, но к рабочей дорожной карте, и приступила бы в реализации. А когда софты тухлые, то каждый сидит в своем пузыре, друг друга никто не слышит - и нет конца бла-бла-бла.
Зависит от цели. Когда цель - быстрее приступить к задаче, то всё именно так как вы написали. А вот когда цель - скрыть отсутствие хард скилов, то все софт скилы направляются именно на растягивание митингов...
Группа разработчиков без умения и желания общаться друг с другом просиживает целые дни на совещаниях? Не видел такого.
По моему опыту, желание всё пообсуждать в широком кругу есть только у неуверенных руководителей. Профессиональные разработчики склонны болтать поменьше, а делать побольше. Лучше потом переделать за полчаса, чем лишний час сидеть теоретизировать в широком кругу
Группа разработчиков без умения и желания общаться друг с другом просиживает целые дни на совещаниях? Не видел такого.
Не, разработчики дисциплинированные и работают, и при этом совещаются строго каждый день, это же аджайл, всё по учебнику. Менеджеры совещаются чуть реже, но обильнее. Скажем, после недели обсуждений решают сделать кастомные контролы, ещё пара недель и UI дизайнер выкатывает решение заменить стрелки инкремента/декремента на плюсики и минусики слева и справа. Свежо, да. Выглядит стендап митинг так: Рамануджан, ты чем занят? Я делаю кнопки инкремента. Ну ОК. Проходит день. Следующий стендап: "я работаю над кнопкой декремента". Я вежливо интересуюсь, чем же она так отличается от инкремента? Скрам мастер ёрзает - технические вопросы мы не обсуждаем. Ну как же - там ведь юзер может натыкать в минус!. "Ну да, а плюсом может натыкать в вечность" - хочу сказать я. Но говорю лишь, что там тоже лимит есть. "Лимиты - это отдельная сториз и следующий спринт". На показе вижу, что нет юнита - этот контрол показывает миллиметры. Но тут проблема - экран настроек не готов. Я его прошу замокать временно это дело, сам он не может, просто ждёт, ну и так далее. На код ревью вижу, что десятичная точка забита в код намертво и торчит как шляпка гвоздя. Вежливо замечаю, что не у всех десятичный разделитель в виде точки, бывает и запятая. "А у нас нет такой сториз, что юзер должен иметь возможность переключить". Нет сториз - нет работы. Серия обсуждений с менеджерами, архитектором и дизайнером и поехали на новый круг сюрреализма.
Из искусства превращается в индустрию, а в индустрии подобная хрень уже никого не удивляет. Инженер иной раз работает урывками между написанием отчетов начальству и совещаниями с этим самым начальством, от которых нет толку, потому что это контроль ради контроля, поддержание в начальстве иллюзии того, что оно что-то понимает и на что-то влияет
Прошёл год (в основном митингов) " - вот и ответ ;-)
О да, я примерно до пятидесятого совещания довольно дотошно вёл дневник проекта (что очень помогло для реалистичной оценки следующих похожих проектов), но мне в общем уже к концу второго спринта стало всё ясно, так что я был полностью готов к "Плану "Б", в виде спасения проекта при помощи допиливания легаси продукта.
Организационная часть важна.
Есть простое правило - не стоит сразу кидаться делать то, что сказал заказчик. Заказчик к вечеру может или передумать или изменить постановку на 180 градусов. А ты уже сделал. И тебе придется сначала всё откатить, а потом исправлять по новой постановке.
Постановка должна устояться :)
[улиточка - сотрудник месяца.jpg]
Тогда заказчик должен доплатить за доработку :) Передумать он может в любой момент, хоть к вечеру, хоть через неделю. Прежде чем кидаться делать, нужно согласовать постановки и убедиться, что есть письменные (хотя бы в виде переписки в чате) свидетельства согласия заказчика с ними. Честно сказать, это не всегда помогает, но иногда всё же помогает.
Тут ньанс в том, что заказчик может попросить сделать другую доработку. А чтобы её сделать нужно откатить изменения по текущей. Одно дело просто с git слить старую версию и доработать, совсем другое дело если нужно вручную откатывать все сделанные изменения. И вот тут уже заказчик может быть не готов оплачивать работы по откату.
не стоит сразу кидаться делать то, что сказал заказчик. Заказчик к вечеру может или передумать
Для этого у нас в штате есть должность, которая называется "ведущий системный инженер". Именно он обсуждает изначальные требования. Часто бывает так, что заказчик их вообще строго сформулировать не может — у него есть лишь "видение", как должна работать система, ну а искусство системного инженера — переложить это дело на бумагу в виде строгих сториз "пользователь жамкает вот по этой кнопке и происходит то-то". Если требования начинают меняться — это проблема именно системного инженера. Ну и очевидно, что чем позже по временной линии проекта они меняются, тем дороже стоят. Ну а кто платит за этот праздник — это уже другой вопрос.
Часто бывает так, что заказчик их вообще строго сформулировать не может — у него есть лишь "видение", как должна работать система, ну а искусство системного инженера — переложить это дело на бумагу
...и именно от его квалификации зависит, сумеет ли он довести заказчика до нервного срыва!
Конечно, у меня была заметная "фора" в виде уже имеющихся наработок
ИМХО, это главное. Въезжать в новую задачу - уже непросто. А если она узкоспециализированная - тем более. Если есть человек, который уже ее почти сделал, вряд ли кто-то со стороны, если у него уже не было опыта решения аналогичных задач, быстро с ней справился.
О нет, тут не совсем этот случай. Во-первых, перед началом проекта я написал полное и очень подробное техзадание, угрохав на это полторы недели. ТЗ было проанализировано, принято, на основе этого были оценены и приняты сроки, 55 недель взялось отнюдь не "с потолка". Во-вторых, существующий продукт уже выступал в качестве рабочего прототипа, не надо было ничего изобретать, а надо было просто сделать тоже самое, только чуть лучше. И в-третьих, в команду были включены инженеры, уже разрабатывавшие софт для рентгеновских систем, им не нужно было объяснять, что такое детектор, калибровка и 16 бит картинка и как её на экране показывать и т.д. Там вся разработка как "по учебнику" шла. Вообще сделать реалистичную оценку сроков в самом начале проекта — это, конечно, непросто, но в данном случае особого давления не было, поскольку система уже кое-как работала на старом продукте. Я научился с годами не профукивать дедлайны, потому что для меня дедлайн выглядит в виде приехавшего крана, который грузит десять-пятнадцать тонн железку на спец грузовик, который отвозит это дело в аэропорт или в порт, а там заказано место на корабле или самолёте. А эа простой конвейера в виде незапущенной вовремя системы — бывает пенальти в виде одного процента стоимости в сутки простоя, а система стоит миллион плюс/минус (и отнюдь не рублей) и вот это вот всё в общем и целом весьма хорошо бодрит и организует.
Я научился с годами не профукивать дедлайны
Респект. При такой подготовке, действительно, непонятно, откуда взялись такие проблемы с реализацией со стороны других исполнителей. Тотальная лень и нежелание разбираться?
Я получил благодарность и небольшую премию
За такое, ИМХО, надо устраивать всем разнос и требовать немаленькую премию.
В данном случае это ошибка управления. Изначально тот, кто руководил проектом, неверно оценил проект, подобрал сотрудников, распределил роли и т.д..
Если говорить о производительности, то работая с единомышленниками, которые хорошо понимают друг друга и понимают задачу, ты выполнили бы работу гораздо быстрее. Вы молодец, но если объединить несколько молодцов, то результат может вырасти в геометрической прогрессии.
Да, конечно, абсолютно согласен. В данном случае возможности моего влияния на руководство были сильно ограничены, я исполнял роль чисто технического консультанта. Вообще для себя я давно вынес, что помимо организационной составляющей (где в идеале всё сокращено до разумного минимума, кода хватает двоих — продукт- и проект- менеджеров, да руководителя команды разработки, снимающего все коммуникационные и орг вопросы) ещё важна архитектурная составляющая, когда проект разбит на компоненты со слабой связанностью и переиспользуемые библиотеки, так что программисты не "толкаются", а фигачат на максималках. Это вообще большое искусство — получить от команды, скажем из пяти-семи человек, более чем пяти- семикратную производительность в сравнении с прогером-одиночкой. Но вполне возможно.
На основе исследования, приведённого ниже будет ясно, что:
только половина разницы в затратах на разработку объясняется разницей между разработчиками
вторая половина объясняется разной производительностью одного и того же разработчика на разных заданиях
Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
По сути, все что тут доказали - это то что факторов много, и повышать производительность можно по-разному. Так никто и не утверждал обратного.
А что мерять производительность сложно, и надо учиться делать это лучше - так это тоже достаточно очевидно.
Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
Миф не в том, что она разная, а в том, что она постоянная. А данная работа как раз и показывает, что она сильно не постоянная.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
Вероятно, это один из факторов непостоянства
Все исследования что я видел, основаны на некотором ограниченном измерении. Если мы намеряли, что Вася быстрее Пети в 10 раз - как можно из этого делать вывод, что он и завтра тоже будет быстрее, если при этом задачи изменятся? Сегодня они бежали на 100 метров, а завтра у них марафон.
Не вижу никаких причин такие исследования обобщать так сильно. Но если послезавтра нам снова бежать 100 метров - я таки поставлю Васю.
Вот так всегда - как бежать, так снова Вася!) Мотивация за его добросовестность.
Ждем когда нейросетки заменят кодирование - стабильно работая без больничных и отпусков.
Тут скорей вопрос не в том, кто лучше бегает Вася или Петя, а в том, что у Васи замеряли скорость бега, а в реальных задачах надо еще иногда плавать и жать штангу. Соответственно разные спецы топы в разных типах задач и при отборе команды это следует учитывать.
Разумеется. Так я об этом в том числе и говорю - все что у нас есть, это результаты конкретных измерений, согласно которым Вася лучше бегает на 100 метров, чем Петя, причем он в 10 раз быстрее. Если кто-то обобщает это на марафон - разве это проблемы того, кто проводил измерение? Кто-то выяснил, что эти коэффициенты далеко не константы? Спасибо, Кэп, но я лично и так догадывался, что производительность изменчива.
Насколько я помню, "миф" (уж в кавычках или без), зачастую преподносился в том виде, что существуют некие "хорошие разработчики" и "просто разработчики", и производительность первых в разы (иногда пишут про десятки раз) выше оной вторых, при этом - ключевой пункт - независимо от опыта. Т. е., согласно "мифу", через какой-то относительно небольшой временной промежуток (зачастую фигурировала цифра в пять лет, а минимально, кажется, мне попадалась и в два года... джва года, Карл!) разработчик упирается в некий непреодолимый потолок, только у "хороших разработчиков" он очень сильно выше. Понятно, что если "хорошего разработчика" посадить делать незнакомую задачу на незнакомом языке, провал в производительности будет ожидаем, но он будет за относительно пренебрежимое время преодолен, и опять "хороший разработчик" будет в десятки раз эффективнее "просто разработчиков", даже сидящих за этими задачами на этом языке плотно и давно. Очень модная тема была лет десять назад, уж не знаю, это она с тех пор на нет сошла, или это я перестал читать авторов, которые её разгоняли...
Именно так. Общественное мнение считает, что у разработчиков есть некоторая собственная производительность, которая сначала растёт, через 5-10 лет упирается в потолок и дальше они с этой же силой работают, пока не выйдут на пенсию. Данная работа как раз и показывает, что подавляющее большинство не имеют такой чётко выраженной производительности и их результаты могут сильно меняться от задачи к задаче
Я лично раз в 5 хуже своих коллег. И тут ничего не поделаешь, кранчи и обучение лишнее только к выгоранию и депрессии привели. Похвала и небольшие повышения зп тоже не вбивают никакие знания и понимания программирования. И на митингах оч сильно видны эти различия с продуктивными коллегами. Так что на личном примере вижу, что х10 не миф.
Вы либо слишком прямолинейный человек, либо "засланный казачок" на этот ресурс. Или разработка программ это не ваше?
Оценивать себя по митингам можно только если ты Ленин. Я на митингах обычно вообще "сижу, туплю". Коллеги что-то обсуждают, живо, бойко, вроде, всё по-делу, не воду льют. Меня иногда спросят, типа, а ты что об этом думаешь, я в ответ: "А?... Эээ... А! Согласен! Замечаний и возражений не имею." Да, ценные идеи и дельные мысли мне, обычно, приходят медленно, туго и вразнобой - но тем же бойко мыслящим коллегам они, зачастую, вообще не приходят! Уже после митинга, бывает, посижу, потуплю, похожу, потуплю, схожу, кофе попью, потуплю - вроде, наконец-то что-то начнёт складываться в башке, вопросы начинают возникать - другие какие-то, на митинге, вроде, не обсуждали. Подойду к коллегам: "Слуште, коллеги, а что по-поводу вот этого вот? - Эээмм... чаво?? - (минут пять объясняешь, пока до них дойдёт) - Хмм... а ведь и правда, хороший вопрос. А чо ты на митинге не спросил? - Не пришло в голову, а вы чо не спросили? - Ну, и нам не пришло..." При том что опыт работы и уровень знания предметной области у нас с ними примерно схожий, каких-либо уникальных знаний темы у меня, как правило, нет.
Такое "дугодумство" часто бывает из-за того что мозг держит в контексте много деталей и склонен на продумывание нюансов.
на митингах обычно вообще "сижу, туплю". Коллеги что-то обсуждают, живо, бойко, вроде, всё по-делу, не воду льют.
Название статьи не соответствует содержанию.
Лучшие от худших судя по всему могут отличаться в 10 и более раз. Но даже на одной и той же выборки лучшими оказывались разные в разных задачах.
Лучшие от худших судя по всему могут отличаться в 10 и более раз.
Всё уже украдено до Вас. Ещё 12 лет назад.
Но даже на одной и той же выборки лучшими оказывались разные в разных задачах.
Об этом и речь. Основной посыл как раз в том и есть, что, вопреки общественному мнению, не существует метрики скорости прибитой к каждому программисту. Для подавляющего большинства скорость варьируется в таких пределах, что невозможно уверенно сказать, кто лучше, а кто хуже
Как по мне модель куда проще. Ошибка найма множится на ошибки управления и возводится в степень шизофреничного восприятия программистов как серийных механизмов, закупленных на рынке труда, которые могут и в козла отпущения и предсказывать будущее и весьма охотно и эффективно работать на любых задачах, которые ему только кинут в пасть аки кость псине. Вот где-то так и получается хорошие и плохие программисты.
Интересная статья. Спасибо. Однако у меня есть технические замечания. Выводы, указанные в статье, мне показались не основанными на представленных исследованиях. Возможно, это связано с тем, что статья является переводом. В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
В ней говорится об оценке производительности, а затем о факторах, которые могут на нее влиять, но ни слова об исследовании этого влияния.
Это не было предметом исследования. Главный вывод в том, что для большинства разработчиков скорость варьируется в таких пределах, что невозможно сказать, что один лучше (или хуже) другого. Лично для меня это было открытием
Задачи программистов имеют разную сложность. К какой области относятся вычисления выше? Крудошлепы, игроделы, большие данные?
А что вообще считать за "продуктивность"? Скорость выдачи кода, решающего какую-то задачу? ИМХО, это еще не показатель качественности решения. Можно быстро реализовать какой-то код, но потом может оказаться, что его трудно развивать, добавлять новую функциональность; в нем могут оказаться подводные камни, из-за чего малейшее изменение может привести к куче багов и т.д.
Возможно, кто-то менее продуктивен, зато пишет более качественный код, делает это более аккуратно, с большей ответственностью и т.д. Как это предлагается оценивать?
Тут вся заноза в основном свойстве информации операция по копированию практически ничего не стоит. Т.е., грубо говоря, если в вашей голове (или на Stack Overflow и т.д.) уже есть наработки, знания, опыт - то выдать готовое решение труда не составит - вы просто выполняете операцию копирования из головы в редактор кода (пусть и с незначительными изменениями). Если же готового решения нет, в голове пусто, опыта нет - тогда может и в 10 раз и более времени уйти на работу.
Если же готового решения нет, в голове пусто, опыта нет - тогда может и в 10 раз и более времени уйти на работу.
Но ведь это и с любыми другими навыками работает.
Условно, если мастер десять лет менял колодки на Солярисе - он может сделать это с закрытыми глазами за полчаса. И если такой же мастер десять лет занимался заменой задней балки на Гранте - то замена колодок вызовет у него затруднения, особенно если нет мануала. А ведь оба десять лет назад выпустились из ПТУ с корочками "Мастер по ремонту ходовой части".
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
Измеряя продуктивность, нужно сразу уточнять, на каком отрезке жизненного цикла ПО она измеряется. У меня много раз было, что условный джун делает задачу, скажем, за час и закрывает её, как решённую. Потом оказывается, что применённое решение работает хорошо только при определённом стечении обстоятельств, да ещё и имеет кучу побочных эффектов. И тогда эту задачу повторно открывают и отдают мне, а я её делаю, к примеру несколько дней. Вот и получается, что джун сделал задачу в десятки раз быстрее меня, вот только за мной её переделывать не пришлось. Также надо иметь в виду, что возврат задач на доработку (в том числе в виде заново открытых багов, когда задача уже на продакшене) негативно влияет на планирование в целом и на общую продуктивность команды, т.к. всё больше ресурсов уходит на фиксы. Это, кстати, довольно типичная картина, когда маленькая команда берётся за слишком сложный проект, не оценив его сложность. Клиент ведётся на обещанную быстроту реализации, но к назначенному сроку получает лишь очень сырую заготовку, а затем всё тонет в бесконечных исправлениях и доработках, что часто заканчивается судами и даже банкротством одной из сторон.
Хотя конечно, если смотреть в разрезе каких-то средних задач, то обычно я их делаю значительно быстрее уловного джуна. То есть, подход оценки продуктивности по количеству затраченного времени при определённых условиях, безусловно, имеет право на жизнь. В то же время, при других условиях, лучше выбрать того разработчика, который будет делать дольше и дороже, но в итоге сделает хорошо.
Для этого студенты должны были прочитать и понять задачу, реализовать решение и протестировать его с помощью заданного набора тестов
должны были прочитать и понять задачу
Увы, это так не работает. Если разработчик не понял задачу, то это не потому что он "забыл её понять", а потому что у него недостаточно опыта или способностей. То же самое касается "заданного набора тестов". Иногда оказывается, что набора никакого нет, но это не значит, что в таком случае можно ничего не делать.
поправьте меня, если я ошибаюсь
в статье автор говорит, что разные разработчики с разной скоростью решают задачи?
и при этом они имеют специализацию в каких-то определенных областях?
мне кажется, ето совершенно очевидно
большой вопрос насчет репрезентативности исследования, есть у меня ощущения, что особо крутые программисты в выборку не попали
Требуя повышения "производительности", вы теряете лояльность сотрудника, особенно, если это не подкрепляется материально. В частности когда были названы реалитичные сроки, а тебе в ответ, а вот Вася сделает это за 2 недели
Мне вообще интересно, как измеряется скорость работы программиста внутри одной команды. Одно дело, когда работа программиста - это "взял задачу с доски, решил, взял следующую". Но гордиться скоростью решения таких задач.. ну такое. "Смотрите, я винтик в колесе, но не просто винтик, а 10x винтик!"
Другое дело, когда это исследовательская задача. На дизайн, на придумывание интересного алгоритма и т.п. И тут уже появляется взаимодействие с командой. Но если ты единственный 10x программист в команде, то объяснить свое решение займет гораздо больше времени, чем собственно проработка этого решения. И все эти 10x затраченное на решение просто нивелируется, усреднившись к скорости работы команды в целом.
Печально признавать, но это все сладкие маркетинговые сказки для фантазеров, которые сами не окунаются в индустрию. На самом деле здесь больше всего работает принцип - максимазации власти(Джеффа Безоса) - нужно заиметь СЕБЕ максимум прав и политик и стараться по макс отдалять от глори-задач коллег-конкурентов, по возможности не давать им никакой инфы, ни доступов, перекидывать на них бессмысленную рутину и топить перфекционизмом и бессмысленными правками, и держать свой авторитет так, чтобы им было трудно возражать. Только так, за счет других, можно выплыть в топ, иначе только один путь - бессмысленно барахтаться в болоте нарастающих обязанностей и понижающихся награждений - топя свои амбиции, мотивацию и таланты. =(
Лучшие от средних отличаются не в 10 раз а примерно в бесконечность. При чем не только среди программистов а в целом среди большинства профессий.
Лучшие хирурги спасают жизни в таких ситуациях, в которых 100 средних не спасут впринципе.
Лучшие адвокаты вытаскивают клиентов из таких передряг, из которых ни один средний не сможет вытащить.
Лучшие программисты закладывают архитертуру и принимают технологические решения, разделяющие успешные проекты от загибающихся под тяжестью багов, тормозов и тех-долга.
Методику сравнения в студию.
На сколько я понял разработчикам кидались мелкие задачи, и на их основе делались выводы по затраченному времени. Проблема в чем, такая специфика задач на фрилансе, на фрилансе работают на готовом коде. Т.е человек спец в той области в которой берет задачу и она не занимает много времени. Для анализа работы этих ребят методика не подходит !!!
В корпоративном секторе есть специфика: командная работа, большие проекты, долгие проекты. Как я понял специфика корпоративного сектора не учитывалась, т.е. не исследовалось читабельность кода, работа со старыми версиями кода, работа в команде. Соответственно для этого сектора исследование тоже не подходит. Что хотели узнать исследователи не понятно?!?!
Как исследование это представляет интерес, но для практического применения его недостаточно.
Это сдельная ситуация. Предполагается, что выводы сделанные на модели верны и в более общих вопросах. Цель исследования была в том, чтобы опровергнуть утверждение о существовании некоторой константной собственной производительности.
Командную работу, читабельность кода и т.п. очень трудно померить. Поэтому, вряд ли они когда-нибудь станут объектами исследования
Развенчание мифа о собственной продуктивности программистов