Комментарии 242
А что делать, если нейросеть слишком медленно выдаёт токены в ответе на запрос?
Был у меня медленый программист, полгода с ним возился потом уволил.
То, что я сам реально делал 1...2 дня он делал 20 дней, и вроде все правильно в результате у него было, но скорость просто ниже плинтуса....
И никакие мотивации не помогали, а причина простая - он долго работал в серьезной госструктуре, оклад мизер, а ответсвенность огромная была, вот он и привык все по 10 раз перепроверять и никуда не торопится.
он и привык все по 10 раз перепроверять и никуда не торопится.
потом уволил.
Здравствуйте, менеджер корпрорации Boeing. Простите, не узнал Вас в гриме.
10 раз всё проверять? У вас нет тестов? Тогда проблема точно не в программисте была.
Так может он тесты как раз таки и пишет, а задачи спускаются бесконечным потокм, да ещё и старую логику/тесты ломают :)
Обновление не сильно доработаной 1с:Бухгалтерии новым релизом Вы будете покрывать тестами?
А когда мержите из гита доработки другого программиста то-же покрываете тестами?
Поговорка "спешка нужна только при ловле блох и при поносе", видимо, чудесным образом в вашей вселенной не работает?
У меня друг нанял сеньера из гугла и уволил через 2 месяца, так как тот все еще изучал проект и не сделал ни одной таски.
Так это плохо или хорошо?
Так это плохо или хорошо?
Да.
А это сарказм или принятие?
Это пост-ирония.
А это сарказм или принятие?
Да.
Это глубокое понимание особенностей логического оператора "ИЛИ".
В биполярном мире, где нет безразличных людей и компьютеров «Сетунь».
Если вы программист, то нельзя говорить, что a ∨ ¬a заведомо верно, поэтому глубокое понимание логического оператора «ИЛИ» как раз к такому ответу не приводит (или, можно сказать, скорее даже от него уводит).
Для маленькой компании - плохо, да и нет там таких задач чтобы долго изучать.
А "друг" пробовал спросить почему так? Может сеньор вник во все процессы и собирался предложить какие-то изменения, я тут вдруг внезапно уволили.
Ну на одном сложном проекте я только доступы 2 недели получал. Онбординг 3 месяца по плану ) Может вы не работали с крупными проектами?
медленный или быстрый — оценочные понятия. Единственный адекватный способ оценки в этом случае — поручать одну и ту же задачу двум программистам, и делать так регулярно
Можно попробовать менее затратный способ, так как за одну и туже задачу придется дважды платить зарплату, ну а на однотипных, но все же разных можно такое практиковать. Задачу оценивают несколько разработчиков и если разработчик который делает задачу сильно не попадает в усредненную, то это он явно не быстрый
придется дважды платить зарплату
Давление жабы чувствую я...
А вы не допускаете, что тот, кто берет однотипные задачи как раз и делает их быстрее, т к уже знает что как куда и сколько это займет? А "медленный" берет разные... Дайте другую задачу "однотипному" и он окажется медленнее "медленного".
Либо другой вариант: в компании "чайка-менеджмент" и "медленному" ломают поток или переключают контекст каждые 15 минут, а "быстрый" просто знает, что "чайку" не надо слушать, работает в берушах, при этом, т к от чаек полностью избавиться нельзя, он тоже работает хуже чем мог бы, но выражается это не в сроках выполнения, а в багах/тех долге в вашем коде, который вылезет потом, когда этот "быстрый" уволится/пойдет на повышение.
Но скорее всего вы верно угадали: вы платите мало и у "медленного" есть "подработка", а с вами он работает по инерции. Так что да, увольняйте 😁
Это работало если бы большинство разработчиков попадали в свои сказанные сроки, но не просто так проекты почти всегда в сроки не укладываются, даже когда опытные менеджеры добавляют запас.
Задачу оценивают несколько разработчиков и если разработчик который делает задачу сильно не попадает в усредненную, то это он явно не быстрый
Петя проработал в компании 5 лет и знает весь код.
Вася проработал в компании 3 года и практически тоже весь код знает хорошо.
Пришёл Федя, который не знает кодовую базу. Вообще. Адекватна ли будет оценка Пети и Васи?
Даю подсказку - нет.
LLM detected
Автор, пиши конкретные случаи. А эти измышления мы как нибудь сами..
Галере дали голос, надо же
Ну вот если перекидывать сотрудников между проектами постоянно, то и будет низкая скорость работы. Настоящая работа над крупным проектом всегда начинается через 2 года. До этого это онбординг, работать можно, но не супер эффективно. Только через два года происходит полная адаптация. И это не я придумал, это основы менеджмента.
А тем, что вы кидаете человека из проекта в проект, вы ему психику ломаете, и работу проекта.
Я знаю многих кто в принципе пару лет работают и меняют место, по различным причинам, большая зарплата или старый проект надоел и нет роста, по этому тут нужен индивидуальный подход, перекидывать всех в подряд, тут согласен не стоит
Онбординг и смена работы в 2 года хорошо коррелируют с моей гипотезой о том, что к этому времени приходит понимание что проблемы проекта являются следствием его бизнес-структуры и системы управления целиком и никакими техниками их не решить. Более того, для бизнеса они в принципе могут быть ограничением его экологической ниши. И тогда даже попытки придумать решения этих проблем это прям пятилетки (мн.ч) и прям риски-риски. И я таких проектов где устоявшиеся решения складывались слезами кровью и пОтом и сменой и собственных команд и оутсорса в сроки ближе к периодам в 10 лет повидал. И эти компании сейчас в лидерах рынка в своих нишах.
По моему опыту, смена работы связана с ростом зп в первую очередь. Ну это старая история, что почти всегда выгоднее перейти на другое место, чем биться за повышение зарплаты на старом.
У новичков еще есть желание попробовать разные технологии и виды компаний, чтобы найти себе по душе, а не зависать на одном месте с одним стеком на всю жизнь.
Ну или банально скукой: за пару лет проект и технологию изучил, принципиально нового уже тут ничего не будет, можно лететь дальше за следующим проектом. И вот тут как раз может помочь совет о смене деятельности.
У нас в проекте, например, есть две основных части: энтерпрайзная (с апи, крудами, веб-сервисами) и алгоритмическая (графы, вычгеом, оптимизационные алгоритмы). Я стараюсь людей между ними туда-сюда время от времени тасовать, чтобы не скучали, и сам решаю лично задачи то в одной части, то в другой. Иначе скучно становится.
к этому времени приходит понимание что проблемы проекта являются следствием его бизнес-структуры
Просто скрип костылей, гнущихся под весом велосипедов, становится чересчур явственным.
Вы еще некоторое время будете пытаться писать так, что бы без костылей и велосипедов, но потом окажется что руководству нужны именно костыли и велосипеды и на Вас будут сильно косо смотреть.
А еще через некоторое время, после того как Вы развесите на всех манагеров ярлыки тупорылых мудаков и умственных уродов и переживете этот этап, Вы заморочитесь вопросом откуда такая тяга к костылям и велосипедам у этих с виду же культурных людей, то начнете понимать непреодолимые противоречия их бизнес-ниши. Просто у манагеров среднего и выше звена не было философии и они не умеют в абстракции и, соответственно в анализ и объяснения.
Но Вы то умеете. И начинаете копать. И обнаруживаете, что методологически верного ответа нет. Совсем нет. А если он вдруг есть, то на него нет денег. И что бизнес балансирует именно перескакивая с костыля на велосипед в меру своих бюджетов и как раз на этих цирковых номерах и зарабатывает небольшую денежку и Вам, соответственно зарплату.
И дальше уже решаете, включаетесь ли Вы в это цирковое фрик шоу на ведущих ролях или ищите новый цирк.
Так и живем.
ПС. К слову если Вы решите включиться в это фрик-шоу и выжимать с бизнесом денюжку с рынка побольше, то правильные чистоплюи Вам здорово подпортят жизнь своими речами начальству о том, что это именно Вы и наделали всех этих костылей, хотя Вы всю грязную работу и сделаете и ответственность на себя возьмете, а они очень осмотрительно будут стоять в сторонке и выжидать удобного момента для бесплатного карьерного роста.
Но включение их в общий контур устройства мироздания это уже видимо следующий этап в просветлении.
Это что за проекты должны быть, где онбординг 2 года. Большую часть реальных коммерческих проектов можно за 2 года выучить так, чтобы как стихи рассказывать.
По моему опыту путь от состояния «где я? кто я? что я тут делаю?» до состояния «открываю дверь в любой закоулок кода небрежным пинком левой ноги, обладаю развитым навыком телепатии, ликвидирую мелкие баги строгим взглядом, крупные — метким плевком» занимает 18 месяцев.
ликвидирую мелкие баги строгим взглядом
Это хорошо, запомню.
По мне так финальная стадия - это примерно "понимаю, куда развивать продукт дальше и могу протолкнуть свои идеи через архитекторов и менеджмент". И это по моему опыту больше описанных двух лет.
финальная стадия это один из двух вариантов: 1) похакал систему и могу пинать за достаточные деньги сколь угодно долго или 2) ловить здесь больше нечего. Все остальные в той или иной мере промежуточные)
По существу же в больших проектах по моим наблюдениям согласен с Вами - больше двух. До этого момента Вы просто бюрократический легковес для менеджмента. В реальности всю полному ответственности вешают гораздо раньше, но это иллюзия ответственности и всем это известно.
Оба скучные какие то ) А как же двигать вперёд науку/технологии?
Вот как раз первый вариант самый адекватный. И опытные ребята именно к этому и стремятся. А двигать технологии, всю жизнь учиться и т.д. это красивые слова для собесов. В реале все хотят ничего не делать и кушать конфеты. И вот такие любители конфет и есть костяк любого бизнеса, а не бегунки, которые за мифическим опытом приходят.
Описанные Вами стадии наступают после описанных мной.
понимаю, куда развивать продукт дальше и могу протолкнуть свои идеи через архитекторов и менеджмент
Это уже сам становишься архитектором. Если сможешь
Скажите мне, как можно выучить реальный коммерческий проект, когда он во первых никогда релевантного описания и не имел, а во вторых динамично изменяется во всех частях, пока ты расскапываешь одну свою? Команда из условных 10 чел по 40 часов в неделю пилит проект со всех сторон, ты пилишь свою сторону, это 10 стилистик программирования, 10 нюансов по железу, 10 смежников, 10 API провайдеров крывых и дырявых как решето в музее и изменяющихся иногда так же динамично, как твой собственный проект.
Так в таких проектах и КПД от их знания/понимания/выучивания никак не доказано. Были таки истории и у меня, считаю, что достаточно изучил проект, когда знаю, что в каком репозитории лежит, что чем собирается, что где как тестируется, и какие цели у компонент проекта. Самое главное здесь, что бардак был до меня, после меня и останется. Но вообще лучше на такое не тратить время в принципе)
В теории - да. На практике - "нам некогда старый код читать, нам нужно новый писать, чтобы к дедлайну уложиться".
Я писал, крупный проект. И онбординг условный. Полноценным сотрудником любой станет через месяц, а вот супер ниньзя швеёй гитаристкой, нужно времени побольше. Выше об этом писали, и я полностью согласен.
Настоящая работа над крупным проектом всегда начинается через 2 года.
Я видел множество компаний с циклом в 2 года - год роста, найма, премий и год спада, увольнений. Так что работа начинается сразу и в полную силу, пока деньги не закончились)
Галеру перекидывают с одного микросервиса на другой пока деньги не закончились. А если начнёт задумываться и спрашивать неудобные вопросы то увольняют.
Галер надо много и суммарно платить им больше чем при нормальном менеджменте. Но галерный менеджер свою премию получит.
Пример: Озон. Влипли они там по полной программе и назад дороги нет
не обещайте заказчику нереальных/неадекватных сроков исполнения, сперва ТРЕЗВО ОЦЕНИТЕ эти самые сроки, учитывая мнение непосредственного исполнителя, и будет вам счастье :)
а стыдливое понятие "технический долг" перенесите в свою личную жизнь - покупайте просроченные/испорченные продукты под обещание продавца "завтра завезём свежее"
извините, что так резко, но уровень нынешних коммерческих разработок оставляет желать лучшего, мягко говоря.
не обещайте заказчику нереальных/неадекватных сроков исполнения
«Но ведь если я не обещаю заказчику нереальных/неадекватных сроков исполнения — их пробещает кто‑то другой!» ©
так ты готов продать заранее неработоспособный (просроченный/испорченный) продукт? весьма :( вот в этом и проблема нынешнего it как в софте так и в харде - за денеШку теряем остатки профессиональных гордости/самоуважения :(((
ПыСы и не надо про бизнес - нормальный бизнес это честность, в противном случае это барыжнечество :)))
Только этот "нормальный бизнес" явно в той же палате мер и весов, где и "настоящий мужчина"/"настоящая женщина"/"а вот сын знакомой зятя подруги".
Потому что норма считается по массе, а по массе в бизнесе выживают именно выкрючивающиеся и барыжнячующие лондонскими мостами и исправлениями(но-это-неточно) в следующем(когда выйдет, если вообще) релизе. А ещё в норме бизнес вообще - прогорает не взлетев, или чуть-чуть подпрыгнув с веточки.
так ты
Во-первых, я не припомню, чтобы я с Вами на брудершафт пил или эхи с одной ноды качал.
готов продать заранее неработоспособный (просроченный/испорченный) продукт?
А на эту тему моего мнения не спрашивает, посему с этими вопросами обращайтесь к ыфыктивным менеджерам, которым почему-то всегда нужен не полностью отлаженный и работоспособный продукт, а минимально работоспособный продукт («а потом допилим»).
Продаем пробник. Если понравился то продаем полный набор. То есть продаем дважды. Profit!
- Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
- Представь что тебе надо разгрузить машину, сколько времени это займет?
- Пару часов
- Это камаз
- 8 часов
- Камаз, груженый песком
- 12 часов
- У тебя нет лопаты и инструментов, только твои руки
- 2 дня
- На улице -40
- 4 дня
- Камаз вообще под водой
- Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
Камаз, груженый песком
У тебя нет лопаты и инструментов, только твои руки
На улице -40
Какой к чёрту 4 дня — там песок наверняка смёрзся отакенными глыбами, без лома (которого по вводной нет) — там вообще ни фига не сделаешь. Разве что попытаться снять задний борт и им как ломом...
"Разгрузить надо до завтра, инструменты сам родишь откуда хочешь, не маленький, чтобы за тобой сопли подтирать. Тушканчиков в помощь не дам - им платить надо. Ну и что, что замерзло всё? Отогревать не умеешь, мне обьяснить тебе как? Короче, хватит ныть, за работу!"
© Эффективная Сова
Чем вы занимались вообще в студенчестве?
Костры-то по вводной никто не запрещал, правда? А дальше ну придется разгребать золу руками, наверное (лопаты нам все-таки обычно не запрещали использовать).
Я так в одно лицо за три дня погреб в Карелии при -25°C выкопал, 3×3м примерно. Расходники: литров 20 соляры, куба два-три дров, топор (в мясо, восстановлению не подлежит), три штыковые лопаты (в шпатели), лом выжил.
Зато в 1991 году за три дня две сотни дойлеров даже крутыши с калашами не делали.
Опытный человек сразу ответит - 2 недели.
Что есть адекватный срок исполнения, если требования могут меняться день за днём и так, что одно изменение не влияет ни на что, а из-за другого может добавиться работы на неделю/месяц?
Что делать, если разработчик работает хорошо, но очень медленно
Вот вам 5 пунктов, чтобы он работал плохо и медленно)))
Простите, методы управления, наверное прекрасны.
Старый анекдот: японский бизнесмен после осмотра производства задает вопрос "у вас план всегда перевыполняется?". Отвечают "да, конечно!". Японец: "предлагаю уволить технологов и нормировщиков и нанять нормальных".
В статье описана ситуация наоборот, поэтому в балансе прибыль / время лучше увеличить время и скорректировать стоимость часа для крутых спецов, которые делают качественный продукт, но "медленно". А тренироваться в управлении на кошках (с) "приключения Шурика"
Ну вот я как-раз такой синьор разработчик, который делает медленно, но заказчик доволен. Потому что я не на конвейере что-то клепаю, а каждый раз делаю то, что ни я, ни кто-то другой тут ещё не делал. Каждый раз нужно разобраться в теме, выучить какие-то новые бизнес-процессы, технологии, библиотеки и написать не тяп-ляп при этом, а хорошо по возможности. При этом код, который писали до меня, выглядит так, как будто делали всё наоборот - писали не особо разбираясь, лишь бы побыстрее. Писали разные люди и довольно по-разному. Расширять функционал такого кода, мягко говоря, нетривиально, попутно приходится делать рефакторинг и стараться при этом не сломать то, что уже как-то работало.
И вот как тут можно работать быстро? Делать абы что, не особо разбираясь? Я так не умею, извините. Мне не за это деньги платят.
Это здорово, но не все же разработчики сеньоры, и ситуации разные и одно дело когда задача стоит реально сложная где нужно хорошо подумать, или нет уже похожего решения и приходится искать свое, но есть ситуации когда разрабочик мидл например, просто часами копается там где можно было спросить у коллег совета и сделать быстрее, при таком же качестве, я писал больше про такие ситуации.
можно было спросить у коллег совета и сделать быстрее
Замедлив работу коллег. Кстати, это еще один вариант 'медленности' -- он просто на вопросы коллег отвечает.
не все же разработчики сеньоры
Прикиньте, сеньоры не на грядке растут, а из джунов вырастают, именно через многократное решение задач, где нужно хорошо подумать.
Знаете, в тех случаях, когда реально процессы не продвигались, и даже частично по моей вине (случаи за мою 30-летнюю карьеру разные бывали), хороший начальник обычно брал вину на себя. Говорил, мол, значит я, как организатор, не смог грамотно организовать процессы. Создание программного продукта - это всегда коллективный процесс. Если "телега не едет", то не всегда виновата лошадь. Может колёса забыли смазать, может лошадь не покормили. Может лошадь волков боится и не хочет ехать. Коллектив - штука не простая, и во многом от руководителя зависит, насколько то же обращение к коллегам за помощью является комфортным для члена коллектива. Может там все загружены так, что нет времени на помощь. Может атмосфера в коллективе такая, что человек себя после обращения за помощью будет чувствовать не комфортно. Может человек вообще не знает, к кому и как он мог бы обратиться. И думает, что должен разбираться во всём сам. Процессами нужно управлять.
Причём в итоге это ещё и выливается в пять-шесть строк кода...
В один символ :). Рекордное исправление было длиной в один символ и потребовало несколько недель работы...
Бывает и так ) А бывало, что в результате рефакторинга легаси кода, я уже имеющийся код уменьшал раза в 2, без потери функционала и даже наоборот - с улучшением расширяемости и т.д.
Бывало что 100 строк я писал две недели, а следующие 3 дня от меня diff +3000 строк, -1500 строк - нейронки рулят
Слышал такое мнение, что если много раз решать сложные задачи качественно, пусть и медленно, то со временем они будут получаться быстрее, при сохранении качества.
Если же сложные задачи стремиться решать быстро, хоть и с потерями качества, то со временем вырастет средний уровень качества, при сохранении скорости.
У первого за плечами будет репутация хорошего мастера, а у второго... вопрос)
Зависит от длительности жизненного цикла продукта. Если ему жить осталось пару лет то и пофиг. Встречал такое.
В идеальном мире вы клепаете блоги и точно можете дать оценку. Но в реале, на больших проектах, при нехватке разработчиков, вы будете выполнять параллельно несколько задачи да еще и на тех проектах с которыми вы плохо знакомы. Если вы реально можете сказать точно оценку, то вы Ванга
Добавьте зарплаты тем кто делает быстро и хорошо и все встанет на свои места
Что делать, если разработчик работает хорошо, но очень медленно
«— Что делать будем?
— Завидовать будем!»
Поднять ЗП не пробовали? Может она ниже рынка и он это знает.
Однако разработка часто требует быстроты — сроки обычно жесткие.
Всё как обычно, бери больше, кидай дальше, да побыстрее, побыстрее (иначе менеджер не получит бонусов). Причём для пользователей ситуация тоже не лучше. В век интернета тенденция "скорее вывалить, а там допилим", сильно усугубляется. И если для чисто онлайн продуктов ещё ничего (при условии быстрого и корректного обновления), то для продукции на физических носителей (имеются в виду консоли), иногда ситуация превращается в какой-то сюр. Как-то купился на отзывы, взял один расхайпленный тайтл (КАЛисто протокол, я о тебе) на диске, а этот кусок Г валился буквально каждые пять минут. Понятно, сразу выпустили патч, вот только рукожопы сделали его размером, сопоставимым с размером исходного "продукта". Да, для анлима 100Гбит это не проблема, но мне нет смысла переплачивать xN только для того, чтобы качать подобные патчи. В итоге диск превратился в некое подобие ваучера, единственный плюс которого в том, что его можно отдать кому-то ещё.
Двоечка за знание психологии.
Медленный — это совсем не обязательно плохой. Неспешность умственной работы может быть вызвана и тем, что школьник обстоятельно и тщательно выполняет все необходимые «операции», постоянно контролирует себя. Специальные исследования показали, что многие из медленно думающих детей глубже вникают в содержание изучаемого, стремятся не воспроизвести текст дословно, а найти свои слова для выражения его главных мыслей. Решая математические задачи, медленно думающие дети часто предлагают более оригинальные пути.
Тугодумы — не такое уж редкое явление среди талантливых, плодотворно работающих ученых. Вот высказывание одного из ученых-математиков: «Разница между двумя типами математического ума: некоторые быстро схватывают и усваивают чужие идеи (из них вырастают эрудиты), другие мыслят более оригинально, но медленнее. Среди творчески одаренных математиков, и притом очень глубоких ученых, немало тугодумов: они не в состоянии быстро решить даже относительно простой вопрос, но зато умеют сосредоточенно и глубоко размышлять в течение длительного времени над очень трудными проблемами. Среди самых обещающих учеников математических классов есть ребята, которые систематически проваливаются на олимпиадах, где требуется решать трудные задачи за короткий срок. И в то же время они решают гораздо более трудные задачи, не будучи ограничены никаким жестким сроком».
Тогда подобным программистам-тугодумам , которые работают хорошо, но медленно, прямая дорога в какие-нибудь RnD-подразделения.
т.е. с галер? Вангую, что с развитием галер они будут избавляться от дорогих медленных сеньоров, а приходить к схеме мальчиков, делающих прям сейчас и задешево с громадным даже не тех. долгом, а просто поделку MVP, закрывающего текущие потребности заказчика и не более, без перспектив какого либо дальнейшего развития проекта вообще.
Иедленные и стабильные уйдут в проектирование уже фреймворков для контор из таких мальчиков.
И конечная устоявшаяся схема (как раз десять-пятнадцать лет понадобится на ее первый релиз) будет выглядеть так:
Коллективы сильных аналитиков, методистов с программистами медленно и вдумчиво делают фреймворки с условным нулевым техдолгом для "среднего заказчика". Фреймворки эти покупаются галерами для допиливания под конкретного заказчика набором постоянно текущих по галере мальчиков. Проект за это время обрастает техдолгом во всех его смыслах как маркитанская шхуна ракушками и водорослями и в конечном итоге лет через 10 начинает идти на дно.
После чего галера идет за новым релизом фреймворка с нулевым техдолгом к его поставщику, заказчику доводится что пришло время заплатить за обнуление техдолга, дорогой, меняется его ПО и весь цикл идет на следующую спираль длинной в 10ку лет.
Но галере да, жизненно необходимы "быстрые мальчики" - это естественная экологическая ниша для процессов, не они первые.
Коллективы сильных аналитиков, методистов с программистами медленно и вдумчиво делают фреймворки с условным нулевым техдолгом для "среднего заказчика". Фреймворки эти покупаются галерами для допиливания под конкретного заказчика набором постоянно текущих по галере мальчиков. Проект за это время обрастает техдолгом во всех его смыслах как маркитанская шхуна ракушками и водорослями и в конечном итоге лет через 10 начинает идти на дно.
Очень похоже на модель франшизы Битрикса. Только там техдолг и легаси ещё и в самом продукте.
Знать бы, где найти применение своему более тщательному подходу, когда из каждого утюга слышишь про быстроту, как мерило ценности сотрудника
Потому что идёт увлекательная игра «перекидывание бомбой с горящим фитилём»: быстро‑быстро делаем свою часть и перебрасываем задачу дальше; у кого в руках она взорвалась — тот и есть самое слабое звено.
Вот тут тестировщики прям напряглись)
Тестировщик ошибается дважды. В первый раз, когда выбирает себе профессию...)
Тестировщики тоже десятикратниками бывают. У них всё, что можно заскриптовать — заскриптовано.
На последнем проекте все падения на проде были связаны с "быстрыми" программистами. Скорость программирования по хорошему только для стартапов важна, на реальных запущенных проектах "медленные" (а на самом деле просто вдумчивые и осторожные) программисты, вполне возможно, намного дешевле обходятся в бизнес попугаях.
Человек, любом случае, сможет сделать некоторое конечное количество работы, как бы вы его не стегали, какую бы морковку не держали перед носом. Да, в исключительных разовых случаях он может выдать чуть больше. Но если мы говорим о ежедневной постоянной работе, то ваша задача как менеджера — знать производительность своей команды и, желательно, каждого ее члена. И исходя из этого планировать сроки и загрузку.
Опять же, не стоит забывать, что эта "производительность" очень условная величина. Во-первых, ее сложно (а то и невозможно) замерить объективно, тут скорее интуитивная оценка менеджера, основанная на опыте работы с конкретной командой. Во вторых, помимо "производительности" есть еще уйма вещей характеризующих конкретного человека — может так статься, что уволив "медленного" сотрудника команда потеряет больше в чем-то другом. В третьих, сотрудники они еще и люди, поэтому производительность всегда плавает в некоторой области... вчера ему жена не дала, а сегодня сосед всю ночь дебоширил, а завтра солнышко и хорошая погода.
Ну а в остальном да, если менеджер знает поганую овцу в команде (критерии поганости могут быть очень разными), может держать её на карандаше до поры, когда можно будет безболезненно для проекта уволить/сбагрить. Ну или параллельно искать более производительного работника, произведя рокировку в конечном счете (это явно небыстрый путь, требующий доп затрат)
Если менеджер напрямую взаимодействует с членами команды разработки минуя тимлида - это очень плохой подход.
Всё описанное в статье - мимо кассы. Есть люди, кто действительно медленно работает, надо садиться рядом или через трансляцию экрана смотреть, как именно человек работает, на что идут основные потери времени. По моему опыту там 50% потерь времени из-за неумелого использования IDE и ещё 50 из-за неумения искать информацию. Я это замечал, когда помогал другим решать их проблемы. Диктуешь человеку строчку кода, а он набирает несколько минут. А там например нужно набрать название интерфейса EntityTypeManagerInterface, человек набирает Entity, получает три десятка нерелевантных подсказок. Он просто не знает, что можно набрать "entyma" и получить нужное. С поиском информации то же самое. В оргомном проекте, где уже есть всё, люди не могут ничего найти и идут в гугл. Или в нейросеть, которой поди ещё объясни, чего тебе надо. А всё дело в банальном неумении или нежелании читать чужой код и документацию. Причём это касается не только джунов, но и людей с десятилетиями опыта.
Но основная проблема тут в том, что те, кто работает быстро, как правило, не понимают, почему именно у них это получается, поэтому и не могут передать свой навык другим.
надо садиться рядом или через трансляцию экрана смотреть
ну если у вас цель склонить человека к заявлению по собственному, то план неплохой.
Это не так делается, что мол давайте приставим к каждому смотрящего. Просто бывают ситуации, когда просят помочь что-то сделать, разобраться в чём-то. Но большинство помогающих в то время, как напарник возится со строчкой кода, просто отвлекаются на свои дела. Меня же часто раздражает, что на помощь другим иногда уходит очень много времени, и поэтому я пытаюсь вникать буквально в каждое нажатие клавиши, чтобы понять, почему работа у человека идёт так медленно. Признаюсь честно, у меня ушло несколько лет на то, чтобы понять, в чём проблема.
Еще может сработать способ "мягкого" (и сопереживающего) смотрящего, который сядет рядом, чтобы тоже "поучаствовать", вникнуть. Если, вдруг, окажется, что производительность работника (например, программиста), резко повысится (в таком формате), то... Можно будет сделать определенные выводы. И присмотреться повнимательней.
А когда-то это называлось "ХР" и считалось жутко модным.
А там например нужно набрать название интерфейса EntityTypeManagerInterface, человек набирает Entity, получает три десятка нерелевантных подсказок. Он просто не знает, что можно набрать "entyma" и получить нужное
Это приходит само, с опытом, после написания сотни названий, особенно, если используете чистую архитектуру, где нужно часто создавать классы/сервисы с их DI зависимостями, на первом сотне, уже задумаешься, а как можно ускорить написание названия классов/интерфейсов :)
Есть люди, к которым не приходит, или ещё пока не пришло. А таких мелких штук очень много, и этому почти нигде не учат. И очень многим это в итоге выливается в потерю работы. Люди читают десятки книг, смотрят месяцами обучающие видео, но нигде этого не рассказывают. А потом приходит менеджер, вроде того, что написал эту статью, и говорит "а давайте покидаем этого чувака между проектами".
Ну вот я в целом не могу работать уже минут через 40 кодинга, я вообще не понимаю откуда мотивация на реализацию у людей за фикс прайс зарплаты берётся(не беря в расчёт идейных любителей программировать в овертайме за бесплатно)
А что именно вы вкладываете в понятие "кодинг"? Непосредственно набор кода или ещё сопутствующие действия вроде дебага и поиска информации? И что вам надо сделать, чтобы восстановить работоспособность после 40 минут кодинга? Переключиться на другой вид деятельности? Провести созвон? Поесть? Поспать? Уйти в саббатикал? Сессия с психологом? Написать комментарий на Хабре?
PS: только не подумайте ничего такого, я просто не понял, что вы имеете в виду :)
Тоже не понял, что такое "40 мин кодинга". Хороший кодинг - это несколько сессий-колбас часов по 6 подряд (бывает и по 10-12 подряд), если задача "толстая". Правки там, анализ, дебаг - уже отдельная тема.
сессии по 40 минут написания кода. Тот же помодоро в эти 40 мин отлично укладывается. Есть сессии по 25 минут, меня в очередное выгорание они прям здорово спасали. Выкладываешь в код все предыдущие микро-идеи. Дальше уже все, генератор микроалгоритма нуждается в подзарядке батареи, необходимо вставать из за компа, на кофе, прогулку, отжимание, поболтать, новости, хабр к слову и т.д.
Через 15 мин повторение. Мы с Вами сейчас общаемся более чем уверен как раз в этот промежуток.
бывает и по 10-12 подряд
Неа, полезного - не бывает. Я вот раньше думал что это я какой-то неадекватный и не могу по 12 часов как хороший раб кодить, а последил за этими двужильными, и заметил что они так-то тоже не могут. Через два-три часа все, тупят, тормозят, творят херню всякую. Но не понимают, и давай давить, а чо, энергетика всосал и опять как новенький. А что это их "как новенький" означает что выхлопа едва на 20%, большую часть которого потом все равно переписывать придется - так это еще понять надо, а мерилом работы считают усталость.
Как это возможно кодить 10-12 часов, если в сутках всего 8 рабочих часов?
Как это возможно кодить 10-12 часов, если в сутках всего 8 рабочих часов?
А думать когда? Или у Вас сразу трясти надо?
Если в рабочих сутках 8 часов, значит, время кодинга + время думанья + время всех рабочих звонков + время всех перекуров + время всех кофепауз не должно превышать 8 часов.
тут главное чтобы из этих 8 часов не было так что 15 минут кодишь 15 минут куришь и 15 минут кофе пьешь а потом еще полчаса думаешь и так по кругу, все 8 часов конечно не реально кодить, даже если созвонами не отвекают, но часов 5-6 в день точно должно тратиться непосредственно на задачи
часов 5–6 в день точно должно тратиться непосредственно на задачи
Если у кого‑то «часов 5–6 в день» тратится на кнопкодавство — то это не программист, а code monkey. А у меня бОльшая часть дня тратится на медитацию по кодовой базе — а потом, как в том анекдоте, «один удар молотком в точно рассчитанную точку — и оно поехало».
В нормальных компаниях под звонки заводятся такие же задачи, как и под всё остальное. И если ты проговорил 8 часов на митингах, можешь с чистой совестью идти домой. С другой стороны, там где время звонков трекается в задачи, вся говорильня сводится к минимуму
Ага, осталось только начать трекать время, затрачиваемое на треканье.
Я думаю, это неплохая идея, чтобы понять, что эти 15 минут в месяц действительно того стоят.
Каких «15 минут в месяц»? Вы реально помните все‑все‑все вещи, которыми Вы занимались вчера?
Нет конечно, не помню. Если мне надо будет это вспомнить, я посмотрю в эксельке с трекингом времени.
Ну и что касается "все-все-все", то это совершенно ни к чему. Если я начал делать задачу в 9.00, с 9:40 до 9:50 я пил кофе, а с 10:20 до 10:25 я ходил в туалет, и в 11:00 я закончил задачу, то в трекинге будет указано, что я работал над задачей 2 часа.
Трекинг - он не про вспоминание. Он про рефлекс 'начал заниматься - нажал кнопку', 'кончил заниматься - нажал кнопку и записал, что это было'.
Частая ошибка - хотеть записать 'что это было' в начале события.
Ну и все это, разумеется, плохо работает и утомительно, когда тебе постоянно между задачами переключаться приходится.
'начал заниматься - нажал кнопку', 'кончил заниматься - нажал кнопку и записал, что это было'.
То есть Вас никогда-никогда не отвлекают на какие-то срочные надовотпрямща задачи? Которые, хоть и занимают не особо значительное время, но могут иметь множественые уровни вложенности?
То есть Вас никогда-никогда не отвлекают на какие-то срочные надовотпрямща задачи?
В момент отвлечения - нажал кнопку и записал, чем занимался. (Можно голосом надиктовать).
не отвлекают на какие-то срочные надовотпрямща задачи?
Вряд ли они настолько срочные, что десяток секунд подождать (пока я фиксирую предыдущую задачу) не могут.
Ну и, как я сказал, если такое происходить действительно часто и постоянно - оно тоскливо, да. Да и сам рефлекс довольно плохо тренируется как раз по причине того, что есть давление, что ты должен заняться новым вопросом немедленно(человек ждет же), а не через 10 секунд.
Частая ошибка — хотеть записать 'что это было' в начале события.
Однако нередко возникает «эффект Википедии» (это когда «начинаешь читать статью про соединения марганца, а через три часа осознаёшь, что читаешь статью про брачные обычаи мадагаскарских пингвинов») — в том смысле, что решение задачи требует сначала решить другую, той — третью, и т.д., в результате чего к концу дня уже забываешь, а какая, собственно, была первая.
15 минут куришь Что?
Осталась самая мелочь — отделить мух от котлет. Я вот, например, нередко перед сном вспомниаю, что я сегодня делал — а наутро встаю уже с готовым решением в голове. Пределагаете мне время сна в «рабочий день» записывать?
те, кто работает быстро, как правило, не понимают, почему именно у них это получается
Я лично прекрасно понимаю: редактор вим вместо гуйных ide и «сначала думаем 80–90% времени, потом пишем код за оставшиеся 20–10%». Больше никаких суперсекретов и нет.
Я умею пользоваться автоподстановкой, но предпочитаю набирать вручную потому что во время набора я обдумываю алгоритм.
Для меня ручной набор это лучший из способов сконцентрироваться на задаче, развивая дополнительно навыки слепой печати, а не качания на стуле, к примеру. Другие дергают ногой, слушают музыку, разминают шею, качаются на кресле и т.д. Это все то, что помогает сосредоточиться и все то, чего разрабы лишаются в опен-спейсе. Может к слову у ТС опенспейс и его спецы вынуждены его болтовню весь день слушать.
Есть люди (и я один из них) которые занимаются визуальным оформлением кода в моменты обдумывания. Много чего есть.
По моему опыту там 50% потерь времени из-за неумелого использования IDE и ещё 50 из-за неумения искать информацию. Я это замечал, когда помогал другим решать их проблемы. Диктуешь человеку строчку кода, а он набирает несколько минут.
По описанию это даже не стажёр, а человек который вообще не умеет в программирование. Не то что даже синтаксисом языка не владеет и работать с IDE не научился, а не развит навык печатания символов на клавиатуре в английской раскладке. Может так получиться, что "сломана" система найма и собеседований и на позиции набрали "вкатунов" с приписанным опытом?
Нет, это не вкатуны. Как правило, это уверенные мидлы или даже сеньоры с реальным многолетним опытом, которые даже в одиночку могут делать довольно сложные проекты, но не очень быстро. В этом и вся загвоздка, что скорость работы не всегда приходит с опытом. Набор кода - это не только печатанье английских букв. При указании сложных типов есть ещё пространство имён, которое никто вслух не диктует. И вот тут даже в соседних комментариях люди пишут, что принципиально не используют автокомплит. Даже если ты золотой призёр конкурса машинисток, набирать импорты 5-6 уровней вложенности - такое себе.
Ну и я там ещё про поиск информации упоминал, а это то из-за чего люди долго думают. Вот буквально вчера нужно было мне выяснить, умеет ли хранилище сущностей определённого типа загружать их по значению вложенных значений составных полей. Большинство людей пошло бы с этим вопросом в гугл или чат гпт, оставшись в итоге ни с чем, и потратив довольно много времени, даже несмотря на то, что это компонент модуля с порядка 100 тысяч установок. А я потратил 30 секунд, чтобы найти этот класс в дереве проекта и ещё минуту, чтобы изучить все методы класса, несмотря на то, что их там несколько десятков, и сам файл длиной несколько тысяч строк.
Чтобы внести изменение в код нужно понять этот код.
А теперь представляем как разработчику дают новый проект. И он несколько дней может только разбираться что уже есть, что нужно сделать и как не сломать то что работает.
Новый человек не всегда может придерживаться архитектуры и сделать как то не так.
Если постоянно менять разработчиков, то код начинает вонять, а поддержка кода становится непосильной.
Такой сложный вопрос нельзя раскрыть в одной статье. Здесь нужна серия публикаций.
"Как правильно измерять скорость работы разработчика."
"Как избежать конфликтной ситуации, из-за разной скорости работы разработчиков."
"Как раскрыть потенциал разработчика, и повысить скорость его работы."
"Ваш руководитель считает что вы работаете слишком медленно. Как убедить его в обратном?"
Ударить плетью, но не сильно, чтобы не повредить программиста и можно было легче измерить его износ в будущем. Если не совершает ошибок и работает недостаточно быстро, то ударить сильнее. А если всё же стал совершать ошибки, то бить плетью надо слабее. Через несколько взмахов плетью можно определить оптимальную силу удара. Перед экспериментом не забудьте закрепить кандалы покрепче к галере.
Да банально люди не хотят чтобы на них накидывали задачи дополнительно, вот и тянут. Нормальный программист всегда старается оптимизировать свою работу, ибо выгорать никто не хочет. Мы не конвейер как нас пытаются представить на рынке, нам постоянно приходится думать, анализировать, так что все на автомате делать не получится, а тем более писать код по 8 часов в день.
Представляю как многих "медленных программистов" доводят до такого состояния. И хочется к каждому эффективному менеджеру или лиду приставить робота с ИИ, чтобы тот считал скорость и гранулярность их "менеджмента" не только во время, но и вне работы.
Раньше дошел до мысли что у меня проблемы со здоровье. Хронический недосып, много курю.. А потом почитал про переключение контекста и понял что в нем основная причина. Причем так все получается что начальник видит только 10% моей работы. Бывает день прошел и по факту ничего не сделано. Хотя весь день что-то делал.
>>Что делать, если разработчик работает хорошо, но очень медленно
НЕ МЕШАТЬ
Что делать, если разработчик работает хорошо, но очень медленно
Накормить ЛСД.
Написание кода составляет меньшую часть работы разработчика.
В большинстве случаев это отладка и обдумывание.
Так же много времени съедает рефакторинг и написание тестов, но это с лихвой окупается в будущем.
У меня были случаи, когда относительно сложные задачи удавалось закрыть за сутки, благодаря тому что был проведен рефакторинг и написаны тесты.
Нужно подойти к человеку и попытаться объяснить, что модель вашей компании - делать удовлетворительно, но быстро.
Если у него так не получается или он не хочет так работать, то расстаться и найти подходящего.
Как человек, который и получал премии за высокую эффективность работы и который получал увольнения за низку - рефлексировал на эту тему, пытаясь найти проблему в себе.
В итоге пришел к простому выводу:
Организация работы влияет на мою скорость.
При плохой организации, при низкой вовлеченности, при плохой постановке задач, при необходимости устанавливать много контактов по задаче(сходи к дизайнерам уточни что написано в дизайне, сходи к артовикам уточни что они успели нарисовать, сходит к тим лиду уточно как он видит решение и.т.п) - скорость реализации задачи падает многократно. И дело не в том, что эти действия занимают времени и требуют синхронизации. Дело в том, что необходимость их все совершать чтобы получить ясную задачу приводит к росту прокрастинации, т.к. вместо решения задачи требуется заниматься левыми делами из-за плохой организации.
Я бы сказал, что вовлеченность разраба в проект - это ключ к эффективности. И сейчас мало кто умеет в вовлеченность.
Когда ваши правки молча выпиливают из кода - это разрушает вовлеченность.
Когда решения по коду в вашей зоне ответственности принимают без вашего участия - это разрушает вовлеченность.
Хотите чтобы разработчик работал эффективность - организовывайте работу так, чтобы он считал успех проекта своей личной ответственность.
Пока вы относитесь к разработчику как к инструменту - разработчик будет относиться к вам как к банкомату.
О нет, похоже, вы намекаете на то, что наши "эффективные менеджеры" недостаточно эффективны?! Нельзя так говорить. Нужно говорить, что работники ленивы и глупы. Да и вообще "народ не тот попался". )
Это удобно, сказать что все дураки вокруг.
Но я на себе убедился, что тоже дурак.
Злился на руководство за то, что вместо того чтобы делать проект мы делаем презентации накапливая техдолг и делая часть работы на выброс ради того чтобы в майлстоун релиз с фичами показать. Злился, что мне не дают делать мою работу так как я хочу.
А потом взял сторонний проект на выходные.... и повторит все теже проблемы: техдолг, работа в мусорку ради майлстоуна, тупые задачи...
Короче, я бы не стал так критичен...
И вот вопрос: а возможно ли безболезненное совмещение в принципе, когда "грамотная работа" не вступает в противоречие с необходимостью продажи? Когда одно как минимум не конкурирует с другим? Или это первородный грех и поиск точки диномического баланса и есть суть бизнеса программирования? Если второе, тогда нужно выходить в еще одно измерение и вводить третье действующее лицо - поставщика нулевого техдолга.
У меня за мою жизнь было всего два раза. Как сейчас помню случай, когда писал софт для одного биржевого брокера. Он меня усадил за компьютер и сказал — «время не ограничено, бюджет не ограничен, но надо, чтобы 100% работало, всегда». Формочку (которую «можно было склепать за два дня»), я делал два месяца — но не потому, что я такой тормоз — а потому, что реально на каждую возможную и невозможную ошибку имелся свой обработчик (ибо от этой формочки реально большие бабки зависели). В процессе, кстати, нашёл два бага в библиотеке API, которую нам дала биржа (отослал им, они исправили).
Нулевой техдолг полезен и необходим там где есть опасность что твой код убьет людей.
Вот например я сейчас пишу код для высоковольтовых батарей, у нас код обязан быть идеальным, и это понимают все, и начальство, и менеджеры, и заказчики. Никакого техдолга, никакой спешки, никаких компромисов, единственное мерило успеха это ноль мертвых людей и ноль пожаров.
Но это идеальная ситуация, конечно. А то я до этого работал в автомотиве, и там надо было постоянно доказывать что весь код в автомобиле должен работать всегда, весь-весь. И были постоянные битвы на этот счет.
Хоть бы раз в жизни увидеть четко поставленную задачу...
Как ТЗ-шник скажу, что я бы сам от такого не отказался. У меня самого не всегда есть время чётко поставить задачу - поторапливают, ставят сроки и т.п. А тут пока в легаси разберёшься, поймёшь, что "вот тут если сделать так, то сломается всё к чёртовой матери" ли ошибку или недочёт где увидишь и надо в ТЗ внести исправление, а оно уже согласовано и отправлено.
И всё. И пиздец.
Жутко не хватает базы знаний, а чтобы её сделать, это надо месяца два угробить только на нормальный анализ. А сделать всё надо вчера. Вроде думаешь, вот это ТЗ будет готово через неделю, а будет оно реально готово только через месяц. Потому что согласования, исправления, и тому подобное.
пока в легаси разберёшься,
...а если не разберёшься, то выходит примерно так.
Ставить задачи "на вчера".
А точно с "быстрыми" нет проблем? А качество кода?
Почаще переводить между проектами - это почти 100%, что с прошлых проектов будут "дергать" за комментариями. А что там в начале статьи? Ну раз он не вписывается в дедлайны, потому что работает на несколько фронтов, то можно и уволить...
А еще не раскрыта до конца тема оценок проекта и подбор соответствующих исполнителей. Это нормально, что опыт и скорость работы у всех разная. Так может это проблема оценки?
И что значит "медленно работает"? Вася быстро пишет кошмарный код, без комментариев, неструктурированный, непродуманный, с копипастом одних и тех же процедур и функций в разных модулях. А Петя код комментирует, где это нужно, продумывает модульность, работает над оптимизацией. А точно вы хотите уволить или перебросить на другой проек Петю?
Проще все. Медленный это тот за которого менеджмент дрючат в текучем моменте. Быстрый - тот за которого премии дают, тоже в текущем моменте. Техдолг же все без исключения сметают под сукно и через n-лет ведения проекта пишут три конверта.
Я из "тугодумов", наверное, а порой и торопыга каких поискать ... Однако, был у меня коллега вчерашний студент, я его считал очень "тугодумистым", ну уж тугодуместее моего. Как то раз в рамках свободной утренней беседы ниачём за кофэ, я обозначил задачку, которая меня заботила (халтурил в это время, что бы не умереть от тоски на основном проекте, ну и других наускивал "на здоровый левак"). Ну "обозначил" и забыл как водится после тренделок.
Но, через выходные он приходит, подводит меня к доске и ... делает доклад минут на 30 с графиками диаграммами, выкладками. В заключение вручает PDF-чик с диаграмкой.
Работа там была проделана основательная по сравнению с важностью самой задачи.
(К тому моменту я задачку по халтуре решил)
Для меня это было серьёзным уроком. Разница между нами в профф. опыте лет далеко за 20, и я опять понял, что не только молодежь пердунов не понимает, но и старпёры не всегда молодёжь в состоянии адекватно оценить.
По мне так "тугодумов" надо пускать на задачи, которые заведомо предполагают погружение, и строить так задачи, что бы "проверить по-бырому" к ним\нам не попадали. Да, и таки, быть рядом, людям же важно поделиться результатами своих погружений - это основа мотивации.
Скорость сильно зависит от контекста:
постановка задачи
погружённость в проект
сложность проекта (скрытый функционал, неявная логика)
"насмотренность" кода (не в узком смысле, а глобально: шаблоны, правила, проверенные практики и тп)
настроение, психологическое состояние, состояние здоровья, стресс и пр.
DX, настройки IDE
наличие АТ, unit тестов
переключение контекста во время работы (это и плюс и минус)
коммуникации с другими членами команда
работоспособность интеграционных компонентов системы
Суть в том что нет "серебряной пули", но есть набор практик, которые помогаю минимизировать убытки/ущербы/потери.
Не забываем, что за сроки в целом ответственный лид. Ну уволишь ты одного разработчика (поможет ли это?) иии: надо искать на рынке замену (это время), потом испытательный и погружение в проект (время). И нет гарантии, что новый разработчик будет лучше справлятся.
Вот вопрос: как гарантировать сроки выполенния задачи, если реализация зависит не только от одного разработчика, но от нескольких команд?
Процитирую одного авиаблогера из Омана:
Однажды умный пилот сказал, а Марк Галлай за ним записал, что "работать быстро... значит, делать медленные движения без перерывов между ними".
Мне вот каждый день приходится работать с тормозным разрабом. Но уволить его не могу, как я себя уволю? :)
Что делать, если разработчик работает хорошо, но очень медленно
Да гнать его в шею, если вам нужен нормальный человек, который работает быстро и хреново.
Это про меня) Меня как-то уволили за то что работал медленно. Из-за постоянных переработок у меня постоянно болела голова при умственной работе и никакие таблетки не помогали. Делал таску, потом отлеживался и дальше другую таску. Ну это ладно, это мои проблемы, что не занимался спортом и разжирел пока кормили фастфудом по вечерам и пока ночевал в офисе.
Но вот мне дали задачу которую я никогда не делал. Ладно бы документация была. Но нет, я сидел и разбирался в коде, что за что отвечает. В итоге оказалось, что надо вон в ту джсонку добавить строчку, в определенный каталог добавить другую джсонку, в третью джсонку добавить эти джсонки, в коде добавить определенные строки, а папки и файлы должны следовать определенным правилам именования и т.д и т.п. Человек, который постоянно делал подобные задачи справлялся с этим за день, но он был в отпуске. Я же дебажил код, разбирался в логике системы и смотрел историю коммитов целую неделю. Из-за этого были прое*аны все сроки(и видимо деньги) и меня уволили...
Есть очень простой алгоритм из 3 шагов. Если разработчик работает хорошо, но медленно:
Попробуйте не отвлекать его по пустякам и непрофильным задачам;
Стал работать хорошо и быстро? Меняйте менеджера, который отвлекал его по пустякам и непрофильным задачам;
Его никто не отвлекал по пустякам и непрофильным задачам? Дайте ему больше времени на разработку и поменяйте менеджера, который закладывал неадекватные сроки.
"Ложка дорога к обеду" - или "Задача решенная несвоевременно, решенной не является". "Хорошо, но медленно" ничем не отличимое от "Быстро, но плохо".
Все 3 пункта базируются на предположении, что абстрактный программист "мудр и светел", а абстрактный менеджер "темен и туп".
В целом, найти менеджера сложнее, чем программиста. Тупых программистов чисто статистически больше чем тупых менеджеров, просто в силу того, что их просто больше.
Найти хорошего менеджера кратно сложнее чем хорошего программиста.
В среднем случае, "если разработчик работает хорошо, но медленно" то, либо он работает "не хорошо"(нужно поручить задачу другому), либо "не медленно"(объективно задача сложная сама по себе). Собственно, выбор из этик двух "или" и есть критерий "хорошего менеджера".
В целом, найти менеджера сложнее, чем программиста.
Как-то в жизни среди менеджеров я видел чаще руками водителей-передастов и чьих-то приблатненных персон, причем в разных странах. В теории вы может и правы, с пометкой найти обьективно подходящего менеджера, да еще и с верифицируемой историей успеха - да, сложнее, чем линейный персонал. Но у менеджера гораздо чаще фактор человеческих неформальных отношений с вышестоящими выстреливает, чем у его подчиненных, думается мне
В ваших вычеслениях совершенно нет места вероятности "сроки поставлены от балды", или там когда какой-нибудь возомнивший о себе продаван наобещал клиенту с три короба, не поинтересовавшись даже сколько его обещания займут.
Почему вам кажется, что AI заменит разработчиков, когда он уже прекрасно справляется с Менеджерскими позициями? Он умеет вникать в людей и находить к ним подходы, у него нет проблем быть доступным 24/7, он не тратит половину рабочего времени чтобы попы начальству нацеловывать и тешить свое самолюбие игрой в "уволю - не уволю". Как по мне, как раз CTO легко выбирает плагин от jira "менеджерский менеджер", и первой таской от него вы идёте на рынок труда, а ваш "медленный" работник ускоряется, потому что на него не накидывают обязанностей, а помогают в работе, думайте...
Я всегда даю заказчику или менеджеру такую простую формулу:
Работу можно сделать:
быстро,
качественно,
дёшево.
Выбрать можно только два варианта из этих трёх.
Говноманагеры всегда выбирают третий пункт. А ведь если просто пообещать разработчику неплохой бонус за сдачу проекта в срок, то 90% медленных разработчиков каким-то магическим образом сразу станут быстрыми. Просто попробуйте...
А можно вообще придти к менеджеру и сказать, что пока не буду получать 300к/нс делать ничего не буду. Сказать то можно разное.
Тоже такая себе идея может быть, человек тебе напряжется сверх нормального за плюшку, сломается, выгорит, и дальше за обычную зп работать уже не захочет.
Это красивый афоризм, но, примерно как все афоризмы, абсолютно бессмысленный.
Я скажу, ну отлично, делайте качественно и столь долго, сколь пожелаете — работа-то сдельная. Я получаю отличный (по условию) продукт, вы впахиваете за копейки. Win-win.
Есть пределы у этой формулы - конкретный разработчик даже если будет очень хорошо замотивирован (финасово и не только) имеет небесконечную производительность. Желания менеджеров же могут запросто быть нереальными.
если разработчик работает хорошо, но очень медленно
По моему у вас тут небольшое противоречие.
Если разработчик работает "хорошо", то он не может работать "очень медленно", потому что скорость – такой же критерий оценки, как и качество кода. Следовательно, если разработчик действительно работает "хорошо", значит, его скорость укладывается в допустимые рамки.
Такой угар, ваше чтиво)))) Работал я с вами на проекте, честно говоря треш полный у вас твориться. До конца даже дочитывать не стал.
Работал в php отделе. Ребята внедряли подобие гексагональной архитектуры в обычный новостной блок с парой форм. Тесты им нахер не нужны, а бизнес логику мы делегируем инфраструктуре потому что так быстрее)))) А вот на хабре поговорим о высоких материях
Как правило, чтобы детально описать задачу, а так же верно оценить ее решение по срокам со всеми подводными камнями, необходимо сперва эту задачу решить. Вся эта оценка, стратегия и анализ, работают в одном случае, когда изо дня в день делаешь одно и тоже. Конвейерные технологии людей испортили.
на опыте, если разработчик пишет быстро, скорей всего в вашей компании не принято отвечать за код своих модулей, скорей всего код через какое-то время переходит к сап команде. вангую, что как только разработчик уволится вы узнаете, что по сути все, что он написал, и что уже оплачено содержит кучу дефектов и огромный технический долг, поэтому все это срочно нужно преписать на другой язык, нынче это GO.
"Одна картинка лучше тысячи слов"
Какой технический долг на проекте, который помрёт быстрее, чем мой хомяк.
когда ожидания уже проданы, а денеги крятутся на сапе, обычно, приходят джуны. так что хомяк сдохнет в любом случае уверенно и быстро.
если корп большой, то после джунов цикл повторится набором сеньеров, без каких-либо выводов как для заказчика, так и для корпа. пока бабки прут как из рога изобилия можно творить любую дичь.
Оценили задачу на 30 часов.
С оценками задач по времени постоянно воспроизводимый бардак, хотя есть очевидные намеки, что контроль по времени на этапе планирования и на этапе реализации - это принципиально разные вещи и делаться он должен принципиально разными способами.
Этап планирования. Когда задачи набираются в условный спринт, то мы решаем условную задачу "упаковки коробок в контейнер" и нам важно их все подобрать так, чтоб они были упакованы максимально плотно (в смысле заполнения). Поскольку естественным объемом спринта является его продолжительность, то предварительная оценка всех задач в часах (на деле - в человеко-часах) является естественной и практически полезной. Но это только первая часть. Оценка задачи в часах тут - это норм.
Этап реализации. Когда задачи передаются на реализацию и в Jira у вас расставлены все исполнители, то к предварительной оценке в часах нужно относиться уже очень условно. Во-первых, задача переходит на реальных исполнителей с конкретными способностями и обстоятельствами и это первая поправка. Во-вторых, реальная многозадачность, фрустрации, форс-мажоры, заболевания, праздники и т.д. - даже при идеальных процессах разработки, способны 4 часа работы превратить в 4 дня/недели ожидания результата. И это самое важное обстоятельство. Здесь уже важна только абсолютная дата, когда задача будет готова.
Поэтому, когда задача назначена на исполнителя имеет смысл вообще отказаться от оценки в часах(за 1 час, за 2 дня и т.д.) и все вопросы про ETA сводить исключительно к вопросу "Какого числа/К которому часу будет готова задача?". В этом случае вопрос о том сколько на неё было запланировано становится вторичным и служит не более чем ориентиром на ожидаемые сроки ее завершения.
Абсолютные сроки исполнителю психологически некомфортно каждый раз сдвигать вправо. В отличии от трекинга "часов на задачу", которые всегда можно поставить "на паузу" под предлогом "я болел/занимался другими важными задачами/был на митингах/ и т.д." и формально затягивать задачу будучи абсолютно правым, поскольку трудоемкость задачи хоть и оценена верно, но никак не включает в себя значимые обстоятельства конкретного исполнителя. Когда на вход подается предварительная оценка трудоемкости и и с исполнителя требуется конкретная дата, когда будет результат - его работа им самим организуется сильно иначе. Это не говоря о том, что контроль исполнения потока задач при такой постановке и для PM становится гораздо более удобным и наглядным.
В 99% случаев упускается главное - ЗАЧЕМ инженеру работать БЫСТРЕЕ своего собственного внутреннего уровня нормы? К потере удовольствия от работы и к выгоранию это приведет непременно, а денег дополнительных сильно много не принесет. Да и бизнес во многих компаниях спешит не потому что это реально необходимо, а потому что конкретным менеджерам так хочется по каким-то личным причинам.
Соглашусь, что умеренный напряг в планах (на 20-30% от "нормы") это ок, но напряг вдвое-втрое опытного работника (который сразу это видит и понимает, что сделать никак не получится) только демотивирует окончательно.
в 99% ЗАЧЕМ инженеру работать быстрее/медленнее объективно понятно по естественным причинам и не требует уточнений. Срочность - это объективная неотъемлемая характеристика множества явлений этого мира, которую невозможно не учитывать. Только ее надо понимать правильно - не как "быстрее", а как "наличие даты, после которой оно уже и не нужно". И работает оно как в сторону увеличения темпов работ, так и в сторону их замедления.
Поэтому срочность сама по себе никакого отношения к "потере удовольствия от работы", "выгоранию", "внутреннего уровня нормы" не имеет. А всё перечисленное возникает из-за неадекватного восприятия ситуации каждой из сторон, как в отношении способностей друг друга, так и в отношении ожидаемых трудозатрат. Но почему это происходит и что с этим делать - это уже другая история.
Какие-то получаются сферические программисты в вакууме.
А на этой планете — применро так:
— Вот API наших партнёров, вот на него документация, вот библиотека, написанная Васей (коллегой из другого отдела), напиши функцию, которая будет делать вызов XYZ и сохранять данные!
— ОК, должно быть несложно, сейчас сделаю.
(Пишет код. Код по всей логике должен работать, но не работает. «Где я ошибся? Тут же негде ошибаться, да и библиотека ж...»)
— Партнёры, что за фигня, я вызываю метод XYZ, а выдаётся ошибка?
— Простите нас, в документации написано XYZ, это ошибка, следует читать XYV. Спасибо, что нашли ошибку, в следующей версии доки будет правильно.
(Переписывает.)
— Васян, что за фигня, через UI у них метод XYV возвращает 33 значения, а твоя библиотека — только 20???
— Ой, блин, бро, звыняй, я сейчас посмотрел — у них, там, оказывается, пажинация по 20 результатов на страницу — а когда я библиотеку полгода назад писал, у меня в худшем случае 18 получалось, вот я и не заметил. Ща только вот эту задачу закончу — и поправлю.
(проходит три дня).
— Партнёры, я теперь вызываю метод XYV, ошибка другая, но всё равно данные не вернулись?
— Извините, наш менеджер не сказал, что нужно включить разрешение на использование метода XYV дла вашей компании, сейчас включим.
(...мог бы писать и дальше, но, думаю, идея понятна).
Ну и как такое предлагаете точно предсказывать?
У нас в команде если происходят не зависимые от разработчика проблемы, то если он о них не молчит или о них и так известно, то и вопросов к нему не будет. Другое дело когда у него у самого что то не получается и он приходит с этим когда уже задачу нужно сдавать, то это совсем другая ситуация
В этом мире ничего невозможно точно предсказывать. Не нужно себя обманывать. ETA - это не предсказания. Это инструмент работы с рисками. У вас постановка вопроса неправильная.
P.S. То что вы описали, к слову, рядовая банальщина, которую предсказать чаще всего совсем несложно. Гораздо интереснее задача выстраивать работу в таких условиях и уметь со всем этим спокойно работать.
постоянно воспроизводимый бардак,
Ну потому, что там пытаются две величины (риски и трудозатраты) упихать в одно число.
Медленно и быстро это такие офигенно расплывчатые категории в разработке. Был у меня проект один, там был супер быстрый разработчик, менеджер нарадоваться не мог. Но удивительным образом этому проекту понадобился медленный я. А дело в том, что быстрый разработчик все делал максимально ситуативно. Надо вкрячить новую кнопку? Он не будет парится с компонентами, просто копирует часть верстки и в прод. Надо сделать новый метод который переиспользует старый код? Не, вынесение функций это для лохов, копирование кода выбор мастеров. Ну и конечно методы длиной в 300-400 строк это обычное дело. Разбираться с уже примененныем архитектурным подходом? Да не, зачем, валим старую архитектуру и колхозим. Когда я пришел то из одного компонента примерно 20 разных сделал для оптимизации производительности и читаемости. Первый месяц я занимался чисто рефакторингом и оптимизацией. Причем как я ни старался быстрый программист так и не изменил своего подхода к разработке. Вот и вопрос, а так ли важна скорость здесь и сейчас если после нее нужно потратить ещё прорву времени на приведение проекта к порядку? Понятное дело тех кто филонит не защищаю, тут ответ прост и понятен.
Бывает что много времени уходит совсем не на кодинг и обдумывание решения, попытаться понять и решить такие ситуации, которые мешают сделать задачу быстрее с тем же качеством, это я хотел донести, я не пытался как то унизить или оскорбить тех кто работает качественно пусть и не очень быстро, что часто в принципе взаимоисключающие понятия, но порой делается совсем не то что требуется по задаче. Часто по задачам можно прикинуть объем, потому что уже делали похожее. И если на такую задачу времени уходит в разы больше то явно есть какая то проблема, я не исключаю тех вариантов когда это проблема не исполнителя а например поставки или процессов или любой другой, но если ничего не делать, то ничего и не изменится, в первую очередь это нужно побеседовать с самим разработчиком, и узнать у него что ему помешало, это можно сделать в удобное для всех время, заранее запланировав. К тому же у нас сделать тяп ляп и в прод никто не даст, есть те кто отвечают за качеством выполнения задач и за качеством кода.
Я, конечно, извиняюсь, но не нейросетка ли это писала?:D
Прям вот по точечкам слева расписано, и как-то воды будто много, повторы себя же есть
Дайте разработчику нормальную зп и периодически спрашивайте чем помочь? Не отмахивайтесь от его просьб
Вроде все логично, зп платиться за рабочий день, а не за количество выполненных задач, так же не раскрыто как понять "медленный" или "быстрый", довольно часто "быстрыми" называют программистов которые как можно быстрее спихивают свои задачи на ревьюера, QA и ему часто их возвращают, а "медленный" вероятно видит это перекидывание и сразу закладывает у себя это время на отдых, нормально проверяет, даёт качество и с первой попытки сдаёт задачу.
Опять же без четких метрик невозможно оценить скорость разработчика.
пишите адекватным языком, не переходя на английские словечки, self-chek и прочее, а также без бллкерови прочей лабуды, даже если вы программист и статья для них, не значит что нужно тут умного строить
Что делать, если разработчик работает хорошо, но очень медленно