Комментарии 60
Каждый разработчик может и должен коммуницировать с заказчиком

Это пять…
Это касается сугубо моего проекта и видения. До этого каждый сам себе что-то «понимал» из задачи в два абзаца и пилил совсем не то, что было нужно заказчику. Прожект менеджера на проекте нет (с нашей стороны), в качестве него выступает член комады со стороны заказчика. Прокт европейский, все только на английском, естественно. Процент недопонимания друг друга немаленький.
оу, извиняюсь. Вот это важное уточнение: «Прожект менеджера на проекте нет (с нашей стороны)».
Я изначально и хотел спросить ещё, а чем же у Вас стали заниматься PM?

Думаю, что неплохо было бы вынести это уточнение в саму статью.

Спасибо за ответ!

Тут большое значение имеет с кем должен коммуницировать разработчик на стороне заказчика. С выделенным и подготовленным для коммуникаций с разработчиком человеком ака продакт аунер — это одно. Со стейкхолдером фичи — другое. С разработчиками заказчика — третье. С каким-то беднягой, которому проект навесили в наказание…

"Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод"
Погодите, а заказчик сам копается в репозитории и разбирается в ветках? Или есть какой-то софт, оборачивающий весь этот процесс во что-то приятное и понятное заказчичу? Тогда расскажите, пожалуйста, что за софт используется

Да не, скорее всего, ему разворачивают на тестовом сервере и он просто смотрит, что получилось. У них во флоу это называется QA on Dev. Только, я бы не назвал проверку со стороны заказчика QA. Скорее, просто тестирование на соответствие ожиданиям. Но может я чего-то не знаю)

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

Мы используем систему управления проектами Atlassian Jira. Все задачи вместе со статусами ведуться в этой системе. В ней же и настроено флоу для работы. Клиент создает в ней задачи и контролирует их там.

Было на многих проектах проще: разработчик и/или CI разбираются с ветками и деплоят на дев окружение, меняют статус задачи на что-то вроде "ready to acceptance" и, опционально, отписываются заказчику в задаче.


Варианты:


  • ветки задачи мерджатся в общую дев/стейджинг/препрод ветку, которая после каждого мерджа деплоится на дев/стейджинг/препрод среду
  • под задачу динамически создаётся отдельная среда из веток задачи со своим базовым доменом типа task-123.dev.example.com и в общую ветку мерджится только после приёмки
  • у каждого разработчика своя среда, которую он сам готовит к приёмке
  • у каждого тестировщика (включая стейкхолдеров заказчика) своя среда, переключение которой на ветки задачи максимально автоматизировано до кнопки/ссылки в джире или типа того.
Звучит так, как будто компания экономит на бизнес/системном аналитике, PM'e и тестировщиках и размазывает эти обязанности по разработчикам.
На аутсорсе это частое явление. Заказчики, в основном, не хотят оплачивать наемный менеджмент со стороны подрядчика (ПМ, аналитики и т.д.). Им нужны только технари, а менеджмент они сами предоставляют. Порой это не самые квалифицированные специалисты, именно в областе ИТ, но они хорошо разбираются в бизнес вопросах и в том, что именно им нужно. Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И это, к сожалению, объективная реальность. Именно поэтому, многие компании требуют знание английского на хорошем уровне и наличие развитых софт скилов. Но это уже другая история ))
Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И

Когда кидают туда программистов с опытом разработки только в атмосфере микроменеджмента и/или условного "водопада", по чёткому ТЗ. "Нулевой" джун может в итоге больше сделать для проекта, чем убеленный таким опытом сеньор. Просто потому что джун будет постоянно переспрашивать постановщика задачи, других разработчиков и т. п., а правильно ли он его понял, показывать промежуточные шаги и т. п., а сеньор "пропадёт" на неделю и принесёт "готовую" задачу" в чётком в соответствии с придуманным им самим ТЗ, потому что без ТЗ он не может, а задача в джтре не ТЗ, а какая-нибудь юзер-стори

Мда… Много умных слов, но, к сожалению, мало смысла в них.
Это публикация написана для самопроверки понимания процесса, и чтобы запиарить себя и линк на блог. Знать значение слов «Jira», «эстимейт», «дедлайн» — это не значит понимать то, что пишите.
Более того, данный подход полностью нерабочий, т.к. здесь отсутствуют основные звенья, поддерживающие даже базовый процесс разработки.
Можно говорить по каждому пункту крайне много…

Скажу про этот:
Приоритеты расставляет либо заказчик, либо тимлид.
Да-чего там… Без разницы… Поменялся приоритет с зависимой задачи и… Ах-да! Обсуждения же ежедневные есть! Ставим хором приоритет одной задачи всю неделю/две, гоняя эту задачу по всем веткам и этапам процесса разработки так, чтобы всё отметить и ничего не упустить?
Спросите:
Зачем, это ж вроде просто?!
Отвечу сразу:
И я вот говорю: зачем так делать? Зачем мешать работать архитектуре проекта (и разработчикам!) самостоятельно и без каких-либо указаний со стороны тимлида или заказчика?
Запомните: Каждый разработчик в проекте должен знать только две вещи: что нужно сделать, чтобы заработал базовый функционал и что нужно будет добавить после того, как он сделает базовый функционал (все приоритеты по своим задачам ставит именно сам разработчик этих задач). Каждый разработчик — свой уровень/блок/функционал в архитектуре проекта.
1. Никаких приоритетов!!! Если появляются приоритеты в задачах — это уже не разработка, а балаган.
2. Не нужно засорять разработчикам мозг доп. задачами, которые не должны быть в предстоящем релизе.
3. Не нужно забирать у них данные им ранее задачи в работу и ссылаться так: «Ой, это не я, это заказчик так захотел». Это косяк именно тимлида, а не разработчика.

PS: И так, можно тут по каждому пункту целую статью писать…

Согласен частично разве что со вторым пунктом. Так что пишите )

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

Тимлид однозначный bus factor и без него работа встанет. У вс тимлиды не болеют и в отпускa не ходят? Разработчики могут назначать друг-другу задачи? Штатного QA вообще нет? Приоритеты могут меняться в любой момент? Все всегда вместе пилят одну фичу даже если это создаёт лишние проблемы с мёрджем? Подробные отчёты на ежедневных митингах? Все разработчики должны сами добывать инфу у клиента? Бррр… Спасибо, но точно без меня :)
Не знаю. На мой взгляд однозначно должны быть и нормальные тестеры.

Плюс ежедневные общие митинги а ля «вчера я сделал это, это и это, а сегодня я буду делать это, это и это» на мой взгляд не несут особого смысла.

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

Нормальные тестеры предполагаются на стороне заказчика, либо заказчик берёт на себя все эти риски.


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


Смотря что называть "заставлять". Я противник того, чтобы в команде работали люди, для которых правила команды не писаны. Если мне правила принципиально не подходят и продвинуть подходящие мне не получается, то я просто ухожу. От других ожидаю того же. Если решили, что каждый по своей задаче коммуницирует с заказчиком/стейкхолдером сам, и незаметно делегировать это коллеге не получается, то должны коммуницировать сами. Можно дополнительно мотивировать, привязав повышения к отзывам от заказчика. Отзыв наравне с остальными вряд ли получится получить, если все коммуникации ограничиваются done, fixed, fixed, fixed

Нормальные тестеры предполагаются на стороне заказчика, либо заказчик берёт на себя все эти риски.

В данном случае я вижу что тесты и ответственность за них просто свалили на разработчиков.

Главное в этих митингах: какие проблемы были, есть или могут быть и кто может с ними помочь.

Ну да. И этим вполне себе можно и ограничится. Зачем нужно остальное?

Смотря что называть «заставлять».

Это значит ставить людей перед выбором: либо делай так, либо увольняйся. Причём в случае с задачами, которые в общем-то не являются чем-то для них стандартным и обычным. Причём не в момент устройства на работу, а когда тебя уже взяли на совсем других условиях.
В данном случае я вижу что тесты и ответственность за них просто свалили на разработчиков.
Все задачи тестирует заказчик
Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод
Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.

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


Ну да. И этим вполне себе можно и ограничится. Зачем нужно остальное?

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


Причём в случае с задачами, которые в общем-то не являются чем-то для них стандартным и обычным.

Ну как сказать, не являются. Вроде даже в ПТУ на программиста учат принимать участие в сборе требований и составлению ТЗ. Ну и по опыту работы в малом ИТ-бизнесе или в среднем не ИТ, нормальное ТЗ — исключение, а не правило.


Причём не в момент устройства на работу, а когда тебя уже взяли на совсем других условиях.

Условия не могут быть неизменными, они постоянно меняются — это жизнь. Если строго по закону (российскому), то должны предупредить за два месяца и если не согласен, то по договоренности могут выплатить зп за 2 месяца. Или просто эти два месяца отработать.

Где тут ответственность свалили?

А это что:
Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.


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

Этого нельзя добиться более простым способом? Банальным burn down'om например? Или просто тем что каждый может посмотреть на статусы и общую ситуацию в трэкере? Зачем кучу времени тратить на «я сделал таск 1 и таск 2 и таск 3 и ....»?

Ну как сказать, не являются.

Так и сказать. Это приятный дополнительный бонус если разработчик такое умеет. Но нельзя ожидать таких умений от каждого разработчика.

Вроде даже в ПТУ на программиста учат принимать участие в сборе требований и составлению ТЗ.

И даже это не означает умение общаться с заказчиком.
Все что написано в статье — это не догма! А всего-навсего частный случай в моей команде. И людей я подбирал именно тех, которые все это могут. Оплата труда вполне сответствующая. Никого выгонять не нужно. В аутсорсинговых компаниях ведется много параллельных проектов. Люди могут мигрировать с проекта в проект. А еще есть оплачиваемый бенч.

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

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

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

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

Это все ИМХО.
И людей я подбирал именно тех, которые все это могут. Оплата труда вполне сответствующая. Никого выгонять не нужно

Извините, а это вот что тогда было:
Кто-то в старой команде не захотел так работать и ушел

?

Есть амбициозные программисты с хорошими скилами и им очень тесно с простыми гребцами в одной лодке.

Ну здорово. Вот пусть они, то есть те кто это хочет и может, и общаются с заказчиками. Можно им даже за это больше платить. Зачем вот прямо всех заставлять это делать?

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

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

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

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

На моём опыте, пресловутое time-to-market в этих фирмах больше чем в тех, где программисты общаются с постановщиками задач напрямую. Даже просто задержки на коммуникации снижают скорость разработки, не говоря об эффекте испорченного телефона.

Может быть. Но при этом я уверен что каких-то других проблем при этом меньше. Или вы так не думаете? :)

Разве что меньше проблем доходит до заказчика. Типа разработчик обматерит заказчика в лице ПМа, а не лично.

Или разработчик что-то неправильно поймёт потому что не разбирается в нюансах отрасли и/или бизнес-процессов заказчика. Или разработчик на общение с заказчиком будет тратить очень много времени. Или разработчик что-то не то ляпнет заказчику. И так далее и тому подобное.

То есть по моему опыту среднего разработчика к заказчику напрямую пускать не стоит. Как минимум без присмотра точно нет.

С присмотром или без — это детали имплементации процесса.


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

А это что:

Для меня это минимально необходимые проверки. Написал код — проверил, что он вообще не ложит сервер в основных сценариях. Тестировщики уже проверяют полностью, но, блин, смержить в общую ветку код, который ты даже не пробовал запустить…


Но нельзя ожидать таких умений от каждого разработчика.

Вроде как это базовые компетенции программиста, определённые даже в профессиональных стандартах. Ему же не продавать что-то заказчику надо, а выпытывать у него, а что собственно он хочет.

Для меня это минимально необходимые проверки. Написал код — проверил, что он вообще не ложит сервер в основных сценариях.

Угу, и если заказчик всё-таки нашёл баги, то никто не виноват?

Вроде как это базовые компетенции программиста, определённые даже в профессиональных стандартах.

Ну у нас такого нет, поэтому мне интересно о чём речь. Не подскажете конкретнее что там и где определено и как это проверяется/учитывается при приёме на работу. Ну то есть там вакансии тоже по стандарту расписаны или как?
Угу, и если заказчик всё-таки нашёл баги, то никто не виноват?

А если штатные тестировщики нашли баги, то кто виноват?


Ну у нас такого нет

У вас это где, если не секрет?

А если штатные тестировщики нашли баги, то кто виноват?

«Штатные тестировщики». Потому что это их зона ответственности.

У вас это где, если не секрет?

Германия, да и пожалуй большая часть ЕС. Наверняка ещё где-то.

Так как конкретно это всё определено в профстандартах и вакансиях на работу? Мне действительно интересно.
«Штатные тестировщики». Потому что это их зона ответственности.

Значит заказчик виноват. Потому что это его зона ответственности при такой работе.


Так как конкретно это всё определено в профстандартах...?

Российский, например https://classinform.ru/profstandarty/06.001-programmist.html. Можно по странице поискать по слову "согласование"


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

Значит заказчик виноват. Потому что это его зона ответственности при такой работе.

То есть в такой ситуации для программиста не будет никаких последствий? Почему-то я в это не верю…

Российский, например classinform.ru/profstandarty/06.001-programmist.html. Можно по странице поискать по слову «согласование»

Я там нахожу только «согласование сроков». Я не так ищу?

В вакансиях обічно такое не пишут

И откуда тогда я должен знать что конкретно от меня требуется? Особенно если в вакансии написано «разработчик» или вообще «software developer»? :)
То есть в такой ситуации для программиста не будет никаких последствий? Почему-то я в это не верю…

Когда работал так, то последствия были обычные для нахождения багов. Не важно кто и когда нашёл.


Я там нахожу только «согласование сроков». Я не так ищу?

Согласование требований к программному обеспечению с заинтересованными сторонами


И откуда тогда я должен знать что конкретно от меня требуется?

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

Когда работал так, то последствия были обычные для нахождения багов. Не важно кто и когда нашёл.

То есть никаких? Или какие?

В хорошей вакансии прописано что-то вроде «участие в сборе требований» или «непосредственное взаимодействие с представителями заказчика».

Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)
Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)

Потому что многие люди не хотят/не могут выходить из зоны своего комфорта. Но это не проблемы бизнеса, а этих людей. Для того, чтобы что-то найти (деньги, людей, процессы, и т.д.), то нужно это искать. А тот, кому хорошо и так, без этой вечной суеты, остаются за бортом возможностей. Люди ушли из проекта. Кто-то на бенч, кто-то в другие проекты. Кого-то потом уволили, после пары негативных отзывов от другого заказчика (вообще очень частый случай). На аутсорсе «отсидеться» не получится — это я гарантирую на 100%.
Потому что многие люди не хотят/не могут выходить из зоны своего комфорта.

А давайте наоборот: вот нанялся к вам человек разработчиком с условием что он будет общаться с заказчиками. А потом через год передумал и заявил «я больше так делать не буду и это не моя проблема, а вам пожалуй стоит выйти из вашей зоны комфорта». Как вы на это отреагируете?

То есть ещё раз: если такие условия ставились заранее и человек на них согласился когда устраивался на работу, то на мой взгляд это не проблема и такой подход вполне легитимен. А вот менять правила игры по ходу это на мой взгляд не дело.

Но это не проблемы бизнеса, а этих людей.

Учитывая нехватку кадров и высокие зарплаты на данный конкретный момент это как раз таки скорее проблема бизнеса.
Мне кажется, что вы очень сильно переоцениваете ситуацию на рынке труда. Наниматели из Европы и США мониторят весь мир, а не только страны бывшего Советского Союза. И наших программистов нанимают не потому, что они такие гениальные, а потому что они дешевые. И нанимают в основном гребцов, так как у них есть свой менеджмент и лиды.

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

А если, вдруг, какой-то компании позарез нужен будет высококвалифицированный специалист здесь и сейчас, то искать на улице никто не будет. Его схантят с другой работы с зарплатой + 1 тыс. долларов, вот и всех делов-то.
Мне кажется, что вы очень сильно переоцениваете ситуацию на рынке труда.

Наверное именно из-за того что я её переоцениваю у нас на фриме постоянно открытые вакансии и мне постоянно приходят предложения от каких-то там HR агенств. А стоит мне выставить своё резюме на каком-нибудь портале, так за пару часов почтовый ящик завален. И ладно бы я был каким-нибудь супер-пупер гением…

И наших программистов нанимают не потому, что они такие гениальные, а потому что они дешевые.

Я не «наш». Ну или не «ваш» :)

Отвечая на ваш вопрос, то такого спеца просто выгонят на мороз.

То есть у других вы такое поведение не приветствуете, но при этом сами себя так ведёте…
Если вы мне объясните, что именно вы мне пытаетесь доказать, то мне будет проще давать вам более конкретные ответы по теме.

Я вам пытаюсь объяснить что отдельные аспекты описаного вами поведения я не считаю этически корректными.


Ну или если по простому, то то что вы местами делаете в простонародье называется "дерьмовый работодатель".

Ну, во-первых, я не работодатель. Работодатель — это аутсорсинговая компания и заказчик, который оплачивает весь этот «праздник жизни». А во-вторых — я всего-навсего описал рабочий процесс, который никому не навязываю. Я могу снять людей с проекта, но уволить я их не могу.

Ну и последний момент: «Нет такой профессии, как хороший парень». Если сотруднику что-то не нравится, то он вправе найти более подходящее место работы. Тут уже вопрос в том, что такие люди не будут получать высоких зарплат. А тот, кто хочет иметь высокий доход, тот будет идти в ногу с заказчиком, ради заказчика, и для заказчика и соответственно, проекта. По другому не бывает.

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


Ну и как бы те люди которые от вас ушли они остались без работы? А те, кого вы взяли на их место, получают больше денег илт меньше?

А вот менять правила игры по ходу это на мой взгляд не дело.

Нормальная ситуация, настолько нормальная, что даже в трудовом законодательстве прописана. Особенно если декларируются agile подходы изначально, где изменения правил игры неотъемлемая часть процессов. Нет изменений — нет agile.

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

А тут вы думаете другая ситуация? На улицу в мороз перед Новым годом? )

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

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

И это я тоже не считаю правильным поведением.

Понимаете это же всегда банальное «как аукнется так и откликнется». И если фирмы начинают себя вести вот так, то и люди в ответ тоже. И в результате все в проигрыше.

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

То есть никаких? Или какие?

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


Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)

Некоторые компании или, скорее, нанимающие менеджеры используют в вакансиях фразы типа "общение только внутри команды" или "общение только с лидом/ПМ" как продающие для людей определённого склада, с которыми им эффективней работать. Пришёл новый менеджер, изменил условия и работа перестаёт быть привлекательной. Человек может и может делать что-то от настройки локального дев-окружения до переговоров с заказчиком, но не хочет. И есть места, где он этого может не делать. Вот и уходит туда. А кто-то другой наоборот, целенаправленно идёт туда, где будет общаться с бизнесом напрямую.

Немного критики. Надеюсь конструктивной :)

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

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

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

Любая фича, если она достаточно сложная, разбивается на много мелких тасок

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

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

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

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

Непонятны еще такие моменты:
Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня.

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

Разработчики в первую очередь выполняют приоритетные задачи.

На митинге тимлид назначает на каждого задачи

Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.

Тот кто выполнял задачу сразу же трекает свое время для этой задачи

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

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

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

Например, есть задача: отправку напоминанию клиенту, что нужно оплатить инвойс. Обычная постановка задачи так и звучит, что нужно сделать такую фичу. И тут возникает ряд вопросов. А отправлять напоминание нужно один раз или много? Если много, то с каким промежутком? А напоминать через мыло или еще и через СМС, вебсокеты и т.д.? А если клиент так и не заплатил, то что делать с этим, до конца дней присылать уведомления? А если нужно останоить рассылку, то при каких условиях? Без ответов на эти вопросы не возможно четко выполнить поставленную задачу. Вот поэтому и нужно подробно описать заказчику, что нужно делать. Если он этого не может сделать или толково объяснить, то я созваниваюсь с заказчиком и мы все это обсуждаем. Я создаю флоу и кидаю на утверждение.

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

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

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

Изначально на проекте было 8 человек. 1 ПМ/аналитик, 1 QA 4 бэкендера и 2 фронтендера. В итоге сроки посрочены, работа топталась на месте, все искали виновных, проект замер. Клиент стал зверствовать и почти всех поувольнял. В итоге, осталось всего 3 человека. Я (пишу и бэк и фронт, выполняю роль и системного аналитика и архитектора, скрам тоже на мне), один бэкендер сениор и один фронтендер сениор. Перформанс увеличился раз в 10! Клиент теперь спокоен, как удав. Затраты уменьшились в разы, скорость увеличилась на порядок.

Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.

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

Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?

Жира — это всего-лишь инструмент с кучей флагов. На каждом митинге мы всегда в курсе всего процесса работы. Фронтендер четко знает, что творится на бэке. Бекендер все знает о фронте. Так как на фронте юзается Реакт, то сам фронтендер в отрыве от бэкенда ничего не сможет сделать и наоборот. Создание одной конкреной фичи — это когда и бэк и фронт синхронно работают над одной задачей, чтобы превратить это в законченный кусок функционала. А так как мы еще юзаем кучу «хайповых» технологий и с десяток дополнительных АПИ сервисов, то не знание всего проекта целиком для кого-либо на проекте подобно смерти.

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

А по факту самого процесса программирования, то мы тратим процентов 70 нашего времени именно на дискуссии, обсуждение бизнес логики, архитектуру и планирование. И только 30% на сам кодинг. В итоге мы успеваем все, так как ничего не приходиться по десять раз переделывать.
Немного поясню смысл первого комментария (хотя, наверное, надо было это сразу сделать). По большому счету я примеры писал не для того, что бы получить на них ответ, а что бы стимулировать более конкретно сформулировать вот такие субъективные факторы. Скорее всего для вас лично это будет даже более полезно, чем для остальных. Хотя бы для того, что бы более осознанно принимать решения.
Это в общем-то не сложно, та же самая аналитическая работа. Как говориться тыжпрограммист :)

Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки.


А если фича может быть закрыта одним программистом, но не в короткие сроки?
А если не одним, но в короткие?
А короткие это сколько?
А почему именно столько?

Ну и так далее до измеримых величин.

Перформанс увеличился раз в 10!


Ну дык это еще в мифическом человекомесяце было отмечено, что увеличение команды скорость разработки не увеличивает :)

А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.
А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.

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

Можно только порадоваться, что у вас все получилось. Такие истории успеха часто слышу от работающих с иностранными заказчиками — у них другая культура и понимание, что подход "надо все переделать и сделать это надо было ещё вчера" не работает.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.