Моя цель, уволить максимальное количество программистов
Слайд с таким посылом недавно попался мне на глаза. Несмотря на кликбейт, она мне понравилась, потому что соответствует моему восприятию мира как владельцу бизнеса. Расскажу вам немного про это и если зайдет, то буду переодически писать посты про связь бизнеса со всем остальным. Тема эта достаточно болезненная, поэтому я буду аккуратен)

Среди разработчиков существует миф, что главное хороший продукт, остальное приложится. Когда разработчик мечтает о стартапе, он думает о том какой стек технологий он выберет, какие фичи реализует и как круто будет масштабировать проект под нагрузками.

В реальности все не так. Продукт имеет гораздо меньшее значение чем маркетинг и продажи. Маркетологи и продажники зарабатывают деньги, а программист их тратит. Никакие фичи не делают так что раз и мы стали зарабатывать больше денег. Максимум на что они влияют, в большинстве случаев, это на удержание пользователей.

Возьмем для примера Хекслет. Вы наверное удивитесь, но в компании работает около 100 человек из которых программистов работающих над платформой фултайм 4 человека. А вот в маркетинге и продажах 30 человек. Хватает ли нам столько программистов? Нет, мы хотим делать намного больше фич чем мы делаем. Будем ли мы нанимать больше программистов? Нет, потому что найм каждого программиста рождает такой сильный расход, что его не так просто окупить. А работа программиста сама по себе эти деньги не приносит.

Как тогда крупные компании нанимают сотнями и тысячами? Правда заключается в том, что большинство этих проектов адово убыточные и нередко существуют на шальные деньги (привет зеленый небанк). А такие проекты как Хекслет, которые живут на свои, должны быть прибыльными, потому что это единственный способ существовать и развиваться.

Все это приводит к тому, что мы максимально внимательно относимся ко всему что мы делаем. Можно что-то решить не разработкой, а административно? Тогда делаем так. Можно использовать готовый сервис, а не писать свое? Делаем так если справимся с поддержкой.

Ребят, мне нужен СТО или близкий к этому человек, который сможет провести обучение порядка сотни человек по темам:

Менеджмент: o2o, командообразование, роли, конфликты, мотивация, методологии
Бизнес: техдолг, управление скопом, приоритизация

Нужен человек с богатым и успешным опытом по всем этим темам + с опытом проведения подобных мероприятий в виде курсов/тренингов/семинаров/мастер-классов.

Писать можно на [email protected], там же обсудим и денежный вопрос. Лайк, шер, алишер

Что я понял о разработке начав общаться с бизнесом
Было время, когда я долго не мог отпустить разработку и мне было страшно от мысли, что я перестану общаться с этим кругом людей, где так здорово можно обсуждать новые фреймворки, функциональное программирование и высокие нагрузки. Но понемногу проблемы и задачи компании меня поглотили и разработки в моей жизни стало не более 10% времени.

Дальше произошло интересное, я вдруг увидел, что общаться с бизнесом не просто интересно, а очень интересно и, что меня особенно поразило, то как изменился формат общения.

Когда между собой общаются владельцы бизнесов в одной нише, то они всегда с жадностью слушают других, пытаясь узнать все до деталей и найти точки улучшения, например, подтвердить и опровергнуть существующие гипотезы, чтобы не тратить на это свои ресурсы. Споры, при этом, возникают редко, так как всегда можно показать работу тех или иных вещей на конечных цифрах. Например в эдтехе есть такой рейтинг, где можно понять кто есть кто и куда мы часто обращаемся https://edtechs.ru/

С разработкой же все часто по другому. При сравнении проектов друг с другом, у разработчиков часто возникает желание не разобраться в том как у них, а скорее получить подтверждение что у нас лучше, что мы правильнее. Причем я сам ловлю себя на мысли, что когда начинаю общаться с девами, то могу не заметить, как оказываюсь посреди спора о том, какой стек для бека надо выбрать или как лучше выстроить систему обработки событий.

В целом, такие споры конечно же нужны, но, все же, разработчики слишком категоричны. Вот так правильно вот так не правильно. Вы делаете по другому, значит у вас не правильно (посмотрите просто реакцию на некоторые мои твитты).

Я думаю, что одна из причин такой ситуации в том, что в разработке практически нет объективных показателей, позволяющих сравнивать команды и проекты между собой. Нельзя понять насколько вот то о чем говорит команда это нормально и сделать проще было нельзя. Все что происходит внутри это магия. Да можно долго рассказывать как все круто на конфах, а потом приходит Маск, увольняет большую часть инженеров и в течение года в разы уменьшает нагрузки, кодовую базу и сложность системы, значительно сокращая стоимость разработки и сопровождения. https://twitter.com/XEng/status/1717754398410240018

Выводов никаких нет, просто наблюдение. А вы чувствуете что-то в среде программистов?

Что отличает разработку от остальных направлений
Последний пост про отношение бизнеса и разработки. Дальше переключимся на технические темы

Когда управляешь компанией, то разработка становится одним из многих компонентов системы, причем в случае Хекслета, довольно автономным, команда отлично справляется и ее не нужно контролировать. Гораздо больше приходится заниматься образовательной частью, финансово-административной, наймом и другими вещами. Но несмотря на это, разработка занимает особое место в система из-за одной особенности, которая в других направлениях так не проявляется.

Речь идет про принятие решений в подразделениях и их дальнейшее влияние на компанию. В большинстве подразделений, ошибки на уровне исполнителей не являются фатальными. Даже если мы потеряли деньги, то сама ситуация обычно легко выправляется исправлением процессов, обучением или заменой людей. Принятие решений сейчас не имеет сильного влияние на решения принятые потом с точки зрения их реализации. Обычно мы можем сказать “забыли что было, делаем по новому”.

Так работает почти везде кроме нескольких направлений среди которых разработка. Главный риск с разработкой связан с тем, что неверно принятые решения сейчас, могут потом тянуть нас вниз годами вплоть до самого конца существования проекта без шансов это изменить. Причем это не всегда зависит от разработки, обстоятельства могут поменяться так сильно, что система просто для этого не преспособлена и это сказывается на time to market. Архитектура проекта имеет чертовски важное значение и поэтому человек, который отвечает за него с технической точки зрения, должен быть очень здравым и прокаченным одновременно.

С этим связана проблема, что при поиске такого человека, никто не может оценить его уровень, в отличии от остальных направлений, где владелец компании либо уже разбирается либо разберется. Поэтому очень часто такие люди являются сооснователями проектов.

Выложили мой доклад "Конечные автоматы как способы значительно упростить логику и понимание кода" https://youtube.com/watch?v=knoVv2ncwVI Если вам кажется что конечные автоматы это что-то на университетском, то обязательно посмотрите

Зачем спрашивать алгоритмы на собесах?
Недавно я записывался в подкасте, где мы с ребятами обсуждали вопрос требований опыта и накрутки опыта. Например в вакансии часто написано +3 года опыта или что-то такое. Многие от этого негодуют, так как увидеть разницу между теми кто в области 2 года и 3 очень непросто. Тут скорее уже зависит от того где и как конкретно провели эти два года человек. В целом, же, отношение со стороны разработчиков к этому скорее негативное, мол нафига они это делают и сами заставляют накрутить опыт, вот вам примеры.

И хотя я согласен, что с точки зрения реальных скилов +5 или +7 не делают разницы в большинстве случаев, мне же все же хочется подсветить эту проблему со стороны нанимающих. Почему многие компании делают такие ограничения. И не только такие. Например ставят на входе алгоритмические задачки или еще что похуже.

А ответ тут очень простой. Если у вас входящий поток больше чем требуется или его качество ниже чем вы бы хотели, то в этот момент начинается подкрутка таким образом, чтобы вход был более качественным. Причем ни у кого нет ни времени ни желании разбираться в том, какой с той стороны гениальный программист и даже со своим небольшим опытом, он даст фору всем остальным. Это все слишком долго и сложно. Гораздо проще выставить формальные критерии, которые оставят такой поток, который достаточно хорош чтобы с ним работать. А что если мы пропустим хорошего? В этом и смысл. Невозможно создать систему которая четко разграничивает правильных людей от неправильных. Если у вас низкие требования, то тогда попадает много ребят, которых вы бы не хотели брать на работу (и тратить ресурсы компании на работу с ними), если у вас высокие требования, то тогда вы начинаете пропускать хороших кандидатов и, что очень важно, это осознанный выбор таких компаний.

Сюда же, во многом, относится требование алгоритмов на собесах, даже если они на практике не понадобятся. Просто таким образом мы регулируем качество потока (а не отдельных личностей) плюс это влияет на культуру компании, так как ребята с таким бекграундом мыслят немного по другому, чем, например, самоучки (типа меня).

Для крупных компаний уровня фанга, гораздо важнее “не впустить в компанию неподходящего кандидата”, чем “упустить хорошего”.

Да от этого бывает больно, но система важнее, чем локальные оптимизации.

Классно об этом написано в книге https://market.yandex.ru/product--uiliam-paundstoun-kak-sdvinut-goru-fudzi-podkhody-vedushchikh-mirovykh-kompanii-k-poisku-talantov/1781729839

Мы готовы врываться снова в эфир! Второй сезон подкаста "Помогите, я джун" можно официально считать открытым!🎉

Выпуск с Кириллом уже на Яндекс.Музыка, YouTube, Spotify и других привычных платформах

Мы ожидали разговора про лайф хаки при подготовке к теоретическим вопросам и практическим заданиям, но Кирилл поднял вопросы о моральной подготовке, стрессе и рассказал много своих историй.

- Что поможет ощутить уверенность в готовности к первым собеседованиям?
- Что о вас скажет ваша реакция на стресс?
- Как подготовиться к теоретическим вопросам и лайв кодингу?

Вот ссылка на сборник тестовых заданий, о которых говорил Кирилл

Понравился выпуск? Нам тоже! Поддержите нас лайком на платформе, где вы прослушали выпуск. Нам это будет очень приятно ❤️

Насколько сложно поменять стек разработки?
Моя грубая оценка такая. Выход на тот же уровень производительности в другом стеке в том же направлении, например, беке или фронтенде займет полгода. Что входит в это время?

Самое простое это изучение нового языка. Для опытного разработчика, переход на соседний язык (та же парадигма) довольно простая задача. Пару недель на основы и еще пару месяцев на то, чтобы постичь более сложные концепции, которые будут встречаться в работе. Сюда же можно отнести адаптацию к новым подходам, которые приняты в языке или являются следствием его дизайна. Например в Ruby много метапрограммирования, в Java шаблонов проектирования, в JavaScript асинхронности, а в Go флоу построенного на горутинах.

Дальше идет экосистема. Вот эта часть пожалуй одна из самых сложных, так как количество библиотек и особенностей их использования в каждой экосистеме невообразимое количество. Чем более навороченная экосистема, тем сложнее и дольше будет этот процесс. Например переход на Spring Boot с фреймворков Rails, Django или Laravel это сложное занятие из-за количества компонентов и их глубины. По некоторым типа Spring Security пишут целые книги.

Ну и последняя часть инфраструктурная. Способы сборки, доставки, саппорта могут отличаться. То как собирается фронтенд это свой собственный мир. У статических языков есть этап компиляции и много построено вокруг этого. У динамики проще всего, но тоже есть свои особенности. В целом этот этап изучается довольно быстро, если конечно вам не приходится настраивать webpack.

Вы меняли стек? Сколько заняло время и откуда куда?

Не могу молчать. Ребят я очень рад тому что почти под каждым постом возникает большая дискуссия. Вы вдохновляете на то, чтобы продолжать писать! За какашку тоже спасибо, она радует глаз 🙂 p.s. Давайте посчитаемся сколько нас тут реально читает. Поставьте какашку если вы видели пост)

Вот вы все спорите про накрутку опыта, и ее причины, а есть проблема поважнее, это эйджизм в IT, компании хотят себе не сильно старых сотрудников, <30 lol

Такой твит написал Сергей Андреев (СТО в XYZ). Я подумал, а чего бы не спросить об этом у моих американских знакомых, чтобы понять, является ли ситуация в России особой или везде плюс минус так или даже хуже. В общем задал я вопрос в группе ребят, которые работают в штатах десяток другой лет и заодно погуглил. И вот что нашел.

Так или иначе, многие слышали что в штатах есть законы запрещающие дискриминацию по возрасту. Об этом не спрашивают, про это не пишут. Многие люди действительно против такой дискриминации и считают что это абсолютное зло. И казалось бы вот оно счастье. Но:

> имхо везде где работал так или иначе смотрят на возраст по нескольким причинам:
- молодые могут пахать днями и ночами, тогда как у возрастных людей семья дети и т.д.
- средний возраст команды, тоже влияет

> С возрастом от тебя ожидается, что ты уже занимаешь лидерские и менеджерские позиции, поэтому 50ти летние Sr или мидлы начинают жаловаться, что их на работу не берут

> Сталкивался с этим на прошлом месте работы когда обсуждали потенциальных кандидатов на должность Front End разработчика и тогда был пик буткэмпов.
Я был на должность директора, но окончательное слово было за VP с которым проводилось последнее собеседование. Примерный ход его мыслей в тот момент:
Человек пошел на bootcamp = он знает только основы новой профессии , в любом случае нужно будет дополнительное внимание и доп обучение со стороны менеджеров и команды. Для кандидата 50+ этот процесс более сложный в силу работоспособности в сравнении с молодежью.
Два способа это обойти, в моем понимании:
- быть на голову выше всех кандидатов, что довольно сложно после 6 мес. обучения
- фейковый опыт в резюме (+ 5-7 лет работы как делают ребята из Индии и Бангладеша) и знание предмета чтобы успешно пройти собеседование, в этом случае возникнет меньше вопросов.

p.s. Насколько часто вы с этим сталкиваетесь?

Можно ли называть синьорами разработчиков с большим опытом, которые

⁃ Не понимают как под капотом работает тот фреймворк, на котором они ведут разработку
⁃ Не умеют пользоваться отладчиком на рабочем языке
⁃ Не умеют писать автоматизированные тесты и не пишут их
⁃ Не владеют навыками функционального программирования и не знают что это
⁃ Не знают ни одного классического алгоритма
⁃ Знают только один язык программирования
⁃ Не используют миграций и ручками вносят исправления в базе данных (для беков)
⁃ Настраивают локальное окружение всегда руками, не используя автоматизацию
⁃ Не знают как работает деплой их приложения/сервиса и не могут его настроить сами


Что вы об этом думаете? Палец ввер можем, палец вниз не можем

На следующей неделе уезжаю в небольшой отпуск, у нас тут день благодарения, редкий случай когда есть возможность вырваться, так как нет школы у детей. Писать врядли получится, но чтобы вам не было скучно, рекомендую почитать мою серию постов "совершенный код", в которых рассказываются неустаревающие вещи про разнообразные технические решения, которые стоит выбирать или на что стоит ориентироваться при их выборе: https://ru.hexlet.io/u/mokevnin/blog_posts Всем чмоки

Как мы нанимаем

Некоторое время назад мы начали собеседовать мидлового rails-программиста в Хекслет и когда я об этом написал, то люди начали спрашивать, а как мы собственно собеседуем. Рассказываю 🙂

Вообще у нас процесс двух-трех этапный. Сначала рекрутер отбирает резюме по формальным требованиям, куда например входит время работы на последних 3-4 работах. Если человек везде скакал работая по полгода, то это не наш клиент. Если решал похожие задачи, то наш. Кстати, сопроводительное работает если оно хорошо написано и раскрывает что-то полезное.

Дальше рекрутер передает отобранных ребят руководителю направления, который уже отмечает тех кто ему интересен.

Следующий шаг это, как мы называем, прескрин, это небольшое интервью с рекрутером, где он задает вопросы по списку согласованному с руководителем направления. Рекрутер на этом этапе не оценивает проф качества, его задача выяснить какие-то детали и затем передать их руководителю. Например один из ключевых вопросов для руководителей это то по каким KPI они работали. Плюс мы всех спрашиваем о том почему они уволились. Единственное, что оценивается рекрутером на этом этапе, это коммуникация. Это важный этап, так как позволяет значительно экономить время нанимающих руководителей.

Дальше уже идет собеседование с руководителем подразделения и специалистами. Этот этап сильно зависит от направления. Конкретно в программировании мы пытаемся понять насколько человек ориентирован на бизнес, а не код ради кода, насколько он может превращать задачи в решения (на примере кейсов) по пути задавая правильные вопросы и как конкретно он пишет код. Подробнее про этот этап у программистов я расскажу в следующим посте.

Для части вакансий в этот процесс встраивается тестовое задание. Где-то оно идет до общения с руководителем направления (но после разговора с рекрутером), где-то после.

Ну и последний этап, который выполняется без участия соискателя, это сбор референсов. Сейчас мы это делаем для всех сотрудников, которых нанимаем. Очень часто помогает избежать катастрофы, когда неопытные нанимающие менеджеры (и даже опытные), пропускают людей, которые плохо себя показали на предыдущем месте или вообще обманывали.

В целом, когда все это выстроено, то весь процесс занимает в районе недели (без тестового). Кстати весь этот процесс делается в талантиксе.

p.s. А как построено у вас? Вам нравится ваш процесс найма?

На той неделе в штатах бомбанула такая история https://twitter.com/GergelyOrosz/status/1729268790033306105 про фейковых докладчиков девушек на конфе. Я не любитель обсуждать такие штуки, но меня кое что зацепило. На эту историю среагировал дядя боб (роберт мартин), который в рунете считается полубогом и дальше понеслось. Прочитайте этот тред в твиттере, чтобы просто быть в курсе происходящего и составить свое мнение.

Как мы собеседуем программистов
В основном мы нанимаем разработчиков на rails которые либо уже фулстек либо с потенциалом на фулстек. Но есть важная особенность. Я никогда не был сторонником брать людей, которые работали именно на том стеке, который мне нужен. Установка была всегда нанимать хороших ребят с любых смежных стеков. Например на нашу позицию отлично подходят те кто работали с бекенд фреймворками типа laravel, django, spring boot и другими, но не микрофреймворками. Наши самые успешные кейсы и ребята как раз были такими свитчерами. Эта особенность сильно влияет на само собеседование. Оно делится на три основные части.

Первая коммуникационная, которая проходит на прескрине с hr, где hr задает вопросы (спроектированные вместе с нанимающим менеджером) и составляет какую-то свою примерную картинку с впечатлением о человеке, о том насколько он впишется в нашу культуру. На этом этапе hr не принимает никаких решенй, он всегда это показывает менджеру, который либо просит назначить собес, либо пишет отказ. В дальнейших этапах коммуникация тоже проверяется, но уже скорее фоном к остальному.

Бизнесовая, где мы узнаем у человека о его опыте взаимодействия с бизнесом. Насколько человек понимает тоб что он делал для чего и как это влияло на бизнес. То как принимались решения, какие были приняты компромисы и совершены ошибки. Как человек ведет себя когда не до конца понимает задачу или видит что это слишком сложно или чувствует что это не поможет. Чем более опытный человек, тем большего погружения в бизнес мы ждем. Например на этом этапе в том числе отсеиваются те, кто фанатично подходит к выбору технологий. Нам ближе люди, которые понимают что технология это следствие задач и они готовы выбирать и изучать инструмент по необходимости.

Вторая часть техническая. Как правило все собеседование длится один час и строится вокруг одного рабочего кейса, который предлагается решить. Кейс подобран таким образом, чтобы его можно было бесконечно развивать в разные направления в зависимости от того что человек ответит. Причем сам кейс никак не связан с технологией, он плюс минус одинаково делается на любом бекендовом фреймворке. Чаще всего я спрашиваю такое: “у хекслета есть аккаунт в страйпе, который шлет чеки людям на почту, после оплаты. Почта передается в страйп при первой оплате, при повторных платежах (в случае подписки) страйп использует эту почту. На Хекслете внедрили смену емейла и получилась ситуация, когда емейл в страйпе старый и человек может не получить чек. Как бы реализовали логику обновления емейла в страйпе при изменении емейла на хекслете”. Само решение этой задачи очень короткое, но по пути здесь всплывает очень много интересных моментов, показывающих реальное понимание вещей. На основе этого мы уже принимаем решение о найме.

p.s. Домашнее задание: напишите в комментарии как бы вы решили эту задачу в вашем стеке

В чем секрет популярности питона? (не простота)
Во многих рейтингах питон занимает первое место по популярности, что порождает всякие мифы на тему того почему так происходит. Очень многие включая совсем новичков любят повторять что питон очень простой и его легко учить. Но мы то с вами знаем, что на базовом уровне такие же простые практически все скриптовые языки. С таким же успехом можно было бы учить js и например мы так делаем не только на Хекслете но и в колледже.

Другой причиной называют наличие большого количества работы. С одной стороны да, если посмотреть на вакансии, то их много, но есть нюанс. Это совсем разные вакансии, среди которых можно выделить:

⁃ Веб программирование (django и вот это все)
⁃ Аналитика
⁃ Администрирование
⁃ Какой-то скриптинг, здесь все остальное

И между этими направлениями нет почти ничего общего, более того, в некоторых из них знание питона это наименьшее из знаний, которыми должны обладать эти специалисты, например админы или аналитики. В итоге получается что если человек учится на одну из этих специальностей, то претендовать на другую без шансов.

Реальная же причина кроется в том, что питон стал намбер ван языком при обучении в системе образования большинства стран. Начиная от школы заканчивая университетами. Да это не единственный язык которому учат, но питона там много и становится больше. Мог ли быть на его месте другой язык? Конечно, питону в каком-то смысле повезло оказаться на этом месте, в чем скорее заслуга людей, которые его продвигали в этой среде, а не самого языка.

p.s. А что у вас было во время обучения в школе и универе?

Вакансии пост. Если вы или ваши друзья разрабатывают на rails/spring boot/asp.net/django/laravel/symfony/любой другой бек фреймворк, в течении года-двух, то мы бы с удовольствием поговорили https://hh.ru/vacancy/88545320 вакансия немного заточена под rails, но на практике мы ищем не только рельсовика (чаще мы даже переучиваем).

Задачи которые мы решаем в ближайшие месяцы:

- выпиливаем страйп и переходим на клаудпейментс для зарубежных карт
- перерабатываем механику проверки проектов наставниками и менторами (довольно большая штука)
- вводим наставников для b2b, у них там своя атмосфера и нужны возможности похожие на групповое обучение хекслета
- готовим хекслет к запуску в латинской америке (тут все включая переводы, события, интеграция систем)
- интегрируем chatgpt в процесс обучения, чтобы он подсказывал по коду и по урокам
- еще 150 тикетов в беклоге, до которых не добрались :)

Чему у нас можно научиться:

- У нас офигенный код и культура разработки. Линтеры, тесты все как полагается. Прагматично, без "покрытие 90%", без юнитов на каждый чих и так далее. Все само собирается на ci, деплоится всеми по тегу в куб. В докер тоже само сворачивается. Весь набор тестов пробегает минут за 5. В продакшен катим по 5 раз в день

- По проекту это сотни тысяч строк кода, около 300 моделей, десяток подпроектов, десятки серверов, много автоматизаций вокруг (сборка и запуск практик), тысячи репозиториев, образов, много сторонних сервисов. Все это обслуживается командой из 3 фултайм кор девелоперов

- Никакого скрама головного мозга. У нас свой процесс, с минимум всяких плясок и чайных церемоний. Если надо адаптируем под ситуацию

- Все разработчики хекслета в процессе учатся и могут во фронт (реакт) в ops (ansible, куб, докер, терраформ, облака, мониторинг, алертинг)

- Разработка очень интегрирована с бизнесом и принимает много участвия в принятии решений. Мы всегда смотрим на то чтобы решать задачи просто, даже если для этого надо поправить бизнес требования. Ребята понимают как их действия отражаются на метриках в том числе денежных. Между продактом и разработкой нет проджектов.

- У нас фронт внедрен как виджеты, это значит что нет всяких сложных схем аля отдельный фронт отдельное апи и надо все дружить. У нас классический рендеринг на беке с шаблонизатором haml/slim. Мы юзаем бутстрап без кастома и всегда легко под него подстариваемся. Экономим кучу времени и не отвлекаемся на верстку (кроме всяких маркетинговых штук, но для этого есть свои люди). Каждый человек делает задачу от начала и до конца и ни от кого не зависит почти всегда. От идеи до выкатил проходит очень мало времени.

- Все наши ребята участвуют в разработке опенсорса, который мы делаем всегда когда можем. Его уже много и если можем делаем больше

- Меня отстранили от разработки и больше в код не пускают :D

Что значит фраза программиста: “задача готова” ?
В зависимости от компании, готовность задачи может определяться как:

⁃ Подготовил пулреквест
⁃ Передал тестировщикам
⁃ Влил в основную ветку
⁃ Выкатил на продакшен

Большинство мест в которых я работал как программист, под готовностью понимали первые три пункта в разных вариациях. Я в этом не видел никаких проблем, до тех пока не случилось две вещи.

Первое я начал интересоваться процессами, познакомился с канбаном, дао тойоты, теорией ограничений и так далее. Тогда стало понятно, что задача которую сделали, но не отгрузили (выкатили в прод), это проблема, так как пока задача висит, ситуация может поменяться и код придется допиливать. Программист в это время уже занят другим и возвращаться обратно ему будет сложно, плюс потраченное время на вспомнить контекст. Остальные же просто не учитывают сделанные изменения в своей работе и при слиянии мы можем получить серьезные конфликты.

Второе, у меня появился собственный бизнес и я увидел что любая задача, которая “сделана”, но ей никто не пользуется, на самом деле является пустой тратой денег. Не важно что она лежит в ветке, важно что это не приносит никакой пользы бизнесу. Особенно это бьет по задачам, которые в итоге зависают на выходные или, что еще хуже, на праздники. Представьте что мы сделали важное изменение перед новогодними, но не задеплоили. Получается что 10 дней потеряны у нас ни аналитики, ни эффекта.

Но есть и еще кое что. Готовность задачи приносит психологическое успокоение, что я свою работу сделал, дальше не моя забота. В итоге любые возникающие сложности, например ошибки на уровне тестирования или деплоя, рождают скорее раздражение, чем желание заниматься задачей, которая уже готова. А хотелось бы, чтобы программист был вовлечен до конца и хотел чтобы его изменение как можно быстрее оказывалось в продакшене.

Исправить эту ситуацию оказалось очень просто. Достаточно поменять семантику слова готовность. Done в наших досках означает что задача уже выкачена и ее результатами пользуются. В таком случае у программистов свербит, что надо приложить усилия и довести ее до конца.

p.s. А что значит “задача готова” в вашем проекте и хорошо ли это работает?