Comments 64
"Jedem das Seine"
"в большинстве команд система устроена так, что от сотрудника ждут не размышлений, а выполнения..."
"Глубокая работа не видна ..."
Да, эти фразы выдраны из контекста, только они отражают большинство реальностей. Этот замечательный метод будет работать только если работодатель, руководство, пользователи будут готовы ждать чего-то большого. Да только у руководства - KPI и заказчики, у пользователей - самые_важные_срочные_дела. И ты на этом фоне ленивая и конфликтная жопа. Пока вывод из статьи только один - ищите того работодателя, который готов и принимает такие сценарии.
Совет из разряда "Не зарабатывай мало, зарабатывай много" )
Кто-то успел заминусовать. Автору плюс в карму и лайк.
По сути верно написано: не надо работать там, где ваши способности не находят настоящего применения, где нужно быстро фигачить и сдавать, фигачить и сдавать... От такой работы не будет морального удовлетворения, а зарплата не покроет очень быстрое выгорание. Видел, знаю.
Нормальное место найти сложно. Я ничуть не религиозен, но тут вполне уместна цитата:
Просите, и дано будет вам; ищите, и найдете; стучите, и отворят вам. (Мф. 7:7-8)
На счёт "больше получает" - всё относительно. Надо учитывать и "как сильно устаёт", и "насколько всё это задолбало".
Хорошая и правильная статья, хотя заголовок крикливый и рекламный.
Более того, даже в более простых задачах часто бывает что винишь себя - вот не сел прямо сегодня и не сделал, а потом на следующий день (например) приходит в голову гораздо более правильное в долгосрочной перспективе решение. Временной период и не день может быть.
Такую работу не всем доверят: контролировать сложно.
Морщить лоб и говорить умные мысли без результатов могут многие и менеджеры это знают.
Безусловно, что-то в размышлениях автора есть, но мне почему-то вспомнился такой анекдот: "По реке плывет лодка. На корме сидит чукча и курит трубку. Его жена сидит на веслах и гребет против течения.- Хорошо тебе, - говорит чукча, - греби себе и греби, а мне думать надо, как дальше жить."
В целом все верно. Создавать что-то новое, проектировать всегда сложнее и дольше чем фиксить мелкие баги у имеющегося функционала. Можно полдня или целый день размышлять над тем как спроектировать новые модели базы данных и как они должны взаимодействовать между собой.
И конечно, лучше сразу писать качественный, масштабируемый, тщательно покрытый тестами и хорошо проверенный код, чем такой, по которому потом надо фиксить кучу багов или что-то переделывать.
С одной стороны, мысли здравые. С другой стороны, я никогда в жизни не поверю, что в реальном мире где-то кто-то измеряет продуктивность по количеству задач. Это то же самое, как написать статью "Хватит есть суп руками" и расписать в статье преимущества ложек.
Почему нет? Я испытываю тревогу, когда не пишу код. Работа тимлида вообще кажется какой-то ненастоящей работой. Типа придут к тебе и спросят: где коммиты? А ты такой, нет коммитов, были созвоны, обсуждения, размышления... В "фигачить код" была моя зона комфорта, там всё просто и понятно.
Пришлось сознательно менять своё отношение к "не настоящей" работе.
Это у вас просто бардак в компании. Когда я был тимлидом, у меня бывало день-два вообще даже IDE не приходилось запускать. При этом время в задачах у меня было залогировано исправно. Просто задачи другие: код-ревью, деплой, звонки. Как итог, все спринты закрывались на день-два раньше срока.
Дело не бардаке, а во внутреннем отношении и силе привычки.
Так у вас тоже бардак был. Хороший руководитель выстраивает процессы так, чтобы команда могла работать самостоятельно. Если он уходит в отпуск на две недели, команда продолжает функционировать как обычно: все знают свои задачи и к кому обращаться. Тимлид выполняет минимальные корректировки процессов, действуя остальное время как обычный разработчик.
Разве работа контрактора (сколько времени зарепортил, за столько и заплатили) это не оно?
кто-то сделал одну задачу — и сэкономил твоей команде два месяца работы
кто-то делает одну. И получает больше.
вообще-то из "сэкономил команде 2 месяца работы" не следует "получает больше"
Если вы руководитель - у вас есть возможность сбросить лажовые и немотивированные задачи подчиненным, а самому делать одну большую и чрезвычайно интересную. В команде выглядит это не очень красиво, омерзительно.
KPI вы себе нарисуете, на подчиненных - пофик.
Работать такая стратегия будет успешно, но только в очень маленьком и простом проекте, т.к. текучка у вас будет лютая.
Я бы ещё сказал, что большая часть задач, которые мы делаем на работе, никому не нужны. Мало кто реально пытается понять, зачем мы создали эту задачу, кто придумал её делать, будет ли кто из клиентов ей пользоваться, зачем вы вообще её делаем, может, лучше поделать что-либо другое.
Да-да... А кто-то сделал одну задачу, и ничего никому не экономил, но получил больше чем ты и этот, который что-то сэкономил...
Тут - как карта ляжет...
камон, парни, ну серьёзно. Неужели где-то считают продуктивность в количестве тасок в день?
ну и если в конторе рулит ИБД, а 90% тасок никому не нужны - валите из такой конторы. Она существует, только пока у инвесторов не кончились халявные деньги.
где-то считают продуктивность в количестве тасок в день?
А как ещё считать продуктивность руководителю, не знакомому с разработкой софта? Ну, скажем, металлургический завод, руководителем проекта назначили заместителя главного инженера (потому что он может объяснить программистам нужны завода), на еженедельных совещаниях от него требуют цифр (на сколько процентов выполнена разработка софта), ну и откуда ему брать цифры?
Программисты за неделю настраивают условный ютрах , красиво раскладывают таски-фичи-эпики, рисуют спринты и дают вполне обоснованную оценку "сколько %% выполнили за последние неделю, спринт, месяц, квартал, год".
Нет, программисты первые месяц-два будут вникать в работу металлургического завода, в бумажки и процессы, которые им нужно оцифровать. Никаких тасок и фич они не разложат т.к. не знают, в каком порядке что делать. А если что-то и разложат (по команде руководства), то это будет взятая с потолка ерунда (за которую программистам потом отвечать).
Валить не надо. Надо доить ее до талого, просто четко понимать что раздача скоро закончится, а пока не закончилась - есть время выучить то что давно хотел, или на халтуре под-ишачить за дабл рейт, или отдохнуть наконец
Если ты скажешь, что целый день думал над архитектурой — и не принял никакого решения, — это не сочтут за работу. Ты не выглядел занятым, а мог параллельно пить кофе, выглядеть расслабленным и как будто «ничего не делал».
Никто не мешает в джире описывать ход размышлений - какие были идеи испробованы и почему от них отказались
Но если одна мысль решит проблему, которую команда разруливала месяцами — все поймут, зачем ты нужен.
Не поймут, к сожалению. В мире постоянной гонки за иллюзиями и микро-чайка-менеджмента, хорошие вдумчивые разработчики, часто, скорее выгорят и сдадутся, чем что-то кому-то докажут.
Это все хорошо. Но такие задачи реально решаются так: день пыжишься, что то ищешь, три дня играешь в шахматы слегка выгорев, затем решение приходит в голову где нибудь на прогулке. Как оценить результат такой деятельности - большой вопрос, потому как большую часть времени просто не работал.
Оценить просто: сколько бизнес потенциально потеряет, если эту задачу вовсе не решать? Вот такая стоимость "не решения".
Именно поэтому часто считаю разумным делать 2 задачи одновременно: одну чисто техническую, одну на подумать. Нет настроения или идей? Пишем простой код. Появилась какая-то идея? Начинаем творить...
Вечная боль в оценке рабочего времени. Если прям не вставая с места, то у меня очень редко и 40 часов в неделю наберётся, и с хорошими шансами вымотаюсь от такого. Если считать всё время, когда в голове рабочие задачи крутятся, редко получается меньше 70. Ну вот и как это "не работал" считать?
Если все будут делать только интересные и клёвые задачи, то кто будет делать неитересные и скучные?
Угу. Меня так раз уволили. За проект, которым с тех пор горжусь. Таски медленно закрывались.
А если я делаю одну задачу в полгода?) Например сейчас виенна выпрямитель на stm32g4, покажите кто делает такие 10 штук в день?
Эту статью же ИИ сгенерил, ведь, так?
Количество vs качество.
Закон Парето. 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%. Для зрелого продукта нужна и та уникальная одна задача, и те 10 проходных. И себестоимость разработки все равно состоит из их суммы.
Вспоминается матрица Эйзенхауэра с его А,Б, В, Г задачами. Микрозадачки создающие ощущение продуктивности это В. Я и сам за собой замечал что хочется забить день лентой из чего-то что создавало какой-то образ занятости, а по итогу ничего и не сделано.
Реально помогают задачи Б и А. И самый большие и масштабные из них как правило идут на антресоль
Есть золотое правило - если что то срочное делать очень долго, оно становится не таким уж срочным! 😀
Есть работа ради работы и денег.
А есть работа, где есть кайфы и удовольствие, а бабки идут сверху, как супер приятный бонус, в идеале, чтобы их становилось всё больше, рос уровень жизни и потребностей.
Снаружи — тишина. Внутри — сложнейшая работа, которая проявится позже.
"Это только с виду я ничего не делаю, на клеточном уровне я очень занят". :)
А вообще, идея статьи мне понравилась. Жаль, мало где ей следуют.
Вспомнил ещё после прочтения видеоролик "Порожняк" из киножурнала "Фитиль". Был снят ещё в 1969м, а до сих пор актуален.
У программистов такой сленг - как у школьников.
В моем случае присутствует проблема курицы и яйца: для того, чтобы человека начали слушать, ему нужно себя проявить, а критерии эффективности -- количество, а не качество кода. Приведу пример другой метафоры, поясняющей ту же мысль. Когда стадо баранов несется к пропасти, а кто-то пытается их остановить, в первый момент кажется, что этот "кто-то" бежит медленнее всех. При этом до поры до времени припасть не видит никто.
Пока ты делаешь 10 задач в день, кто-то делает одну — и получает больше