Комментарии 62
Каждый разработчик может и должен коммуницировать с заказчиком
Это пять…
Тут большое значение имеет с кем должен коммуницировать разработчик на стороне заказчика. С выделенным и подготовленным для коммуникаций с разработчиком человеком ака продакт аунер — это одно. Со стейкхолдером фичи — другое. С разработчиками заказчика — третье. С каким-то беднягой, которому проект навесили в наказание…
"Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод"
Погодите, а заказчик сам копается в репозитории и разбирается в ветках? Или есть какой-то софт, оборачивающий весь этот процесс во что-то приятное и понятное заказчичу? Тогда расскажите, пожалуйста, что за софт используется
Было на многих проектах проще: разработчик и/или CI разбираются с ветками и деплоят на дев окружение, меняют статус задачи на что-то вроде "ready to acceptance" и, опционально, отписываются заказчику в задаче.
Варианты:
- ветки задачи мерджатся в общую дев/стейджинг/препрод ветку, которая после каждого мерджа деплоится на дев/стейджинг/препрод среду
- под задачу динамически создаётся отдельная среда из веток задачи со своим базовым доменом типа task-123.dev.example.com и в общую ветку мерджится только после приёмки
- у каждого разработчика своя среда, которую он сам готовит к приёмке
- у каждого тестировщика (включая стейкхолдеров заказчика) своя среда, переключение которой на ветки задачи максимально автоматизировано до кнопки/ссылки в джире или типа того.
Поэтому, когда в такой проект кидают только программистов без опыта управления и общения напрямую с заказчикамы, то проекты, как правило, проваливаются. И
Когда кидают туда программистов с опытом разработки только в атмосфере микроменеджмента и/или условного "водопада", по чёткому ТЗ. "Нулевой" джун может в итоге больше сделать для проекта, чем убеленный таким опытом сеньор. Просто потому что джун будет постоянно переспрашивать постановщика задачи, других разработчиков и т. п., а правильно ли он его понял, показывать промежуточные шаги и т. п., а сеньор "пропадёт" на неделю и принесёт "готовую" задачу" в чётком в соответствии с придуманным им самим ТЗ, потому что без ТЗ он не может, а задача в джтре не ТЗ, а какая-нибудь юзер-стори
Это публикация написана для самопроверки понимания процесса, и чтобы запиарить себя и линк на блог. Знать значение слов «Jira», «эстимейт», «дедлайн» — это не значит понимать то, что пишите.
Более того, данный подход полностью нерабочий, т.к. здесь отсутствуют основные звенья, поддерживающие даже базовый процесс разработки.
Можно говорить по каждому пункту крайне много…
Скажу про этот:
Приоритеты расставляет либо заказчик, либо тимлид.Да-чего там… Без разницы… Поменялся приоритет с зависимой задачи и… Ах-да! Обсуждения же ежедневные есть! Ставим хором приоритет одной задачи всю неделю/две, гоняя эту задачу по всем веткам и этапам процесса разработки так, чтобы всё отметить и ничего не упустить?
Спросите:
Зачем, это ж вроде просто?!Отвечу сразу:
И я вот говорю: зачем так делать? Зачем мешать работать архитектуре проекта (и разработчикам!) самостоятельно и без каких-либо указаний со стороны тимлида или заказчика?Запомните: Каждый разработчик в проекте должен знать только две вещи: что нужно сделать, чтобы заработал базовый функционал и что нужно будет добавить после того, как он сделает базовый функционал (все приоритеты по своим задачам ставит именно сам разработчик этих задач). Каждый разработчик — свой уровень/блок/функционал в архитектуре проекта.
1. Никаких приоритетов!!! Если появляются приоритеты в задачах — это уже не разработка, а балаган.
2. Не нужно засорять разработчикам мозг доп. задачами, которые не должны быть в предстоящем релизе.
3. Не нужно забирать у них данные им ранее задачи в работу и ссылаться так: «Ой, это не я, это заказчик так захотел». Это косяк именно тимлида, а не разработчика.
PS: И так, можно тут по каждому пункту целую статью писать…
А мне в целом нравится, кроме бас-фактора
Нормальные тестеры предполагаются на стороне заказчика, либо заказчик берёт на себя все эти риски.
Главное в этих митингах: какие проблемы были, есть или могут быть и кто может с ними помочь. Ну и шаринг общего прогресаа достижения текущих целей команды.
Смотря что называть "заставлять". Я противник того, чтобы в команде работали люди, для которых правила команды не писаны. Если мне правила принципиально не подходят и продвинуть подходящие мне не получается, то я просто ухожу. От других ожидаю того же. Если решили, что каждый по своей задаче коммуницирует с заказчиком/стейкхолдером сам, и незаметно делегировать это коллеге не получается, то должны коммуницировать сами. Можно дополнительно мотивировать, привязав повышения к отзывам от заказчика. Отзыв наравне с остальными вряд ли получится получить, если все коммуникации ограничиваются done, fixed, fixed, fixed
В данном случае я вижу что тесты и ответственность за них просто свалили на разработчиков.
Все задачи тестирует заказчик
Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод
Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.
Где тут ответственность свалили? Мы как-то очень по разному понимаем последнее предложение? Для меня оно означает, что нужно хотя бы проверить что в простейших сценариях код не падает.
Ну да. И этим вполне себе можно и ограничится. Зачем нужно остальное?
Для поддержания в команде общего понимания где мы сейчас, сколько прошли и сколько осталось.
Причём в случае с задачами, которые в общем-то не являются чем-то для них стандартным и обычным.
Ну как сказать, не являются. Вроде даже в ПТУ на программиста учат принимать участие в сборе требований и составлению ТЗ. Ну и по опыту работы в малом ИТ-бизнесе или в среднем не ИТ, нормальное ТЗ — исключение, а не правило.
Причём не в момент устройства на работу, а когда тебя уже взяли на совсем других условиях.
Условия не могут быть неизменными, они постоянно меняются — это жизнь. Если строго по закону (российскому), то должны предупредить за два месяца и если не согласен, то по договоренности могут выплатить зп за 2 месяца. Или просто эти два месяца отработать.
Есть амбициозные программисты с хорошими скилами и им очень тесно с простыми гребцами в одной лодке. Но проекты, на которых они работают, не могут предложить им большего. Мой проект может. В любом случае, при таком подходе, люди с моего (вернее проекта компании) проекта становятся более подготовленными и желанными для заказчика.
Что касается про прием на работу на одних условиях, а потом смена на другие условия. Такого понятия вообще нет. Проект от проекта могут очень сильно отличаться. Помимо собеседования в компанию, нужно еще постараться пройти собеседование с заказчиком, так как именно он платит деньги и хочет знать, с кем ему придется работать.
Главное условия для соискателя — это набор определенных профессиональных и личностных качеств в обмен на достойную зарплату и бонусный пакет. Поэтому все может меняться очень сильно в течении года.
Профессиональных программистов в отрыве от бизнеса не существует. Сами по себе они ни кому не нужны. Именно по этому балом правит бизнес, которому и нужно создать решение. А если учесть, что это высоко конкурентная сфера, то заявлять заказчику, что он тебе не интересен и ты не будешь работать так, как это нужно для проекта, означает остаться за бортом и плавать в маленьких шлюбках третестепенных контор.
Это все ИМХО.
можно создать «прослойку» между программистами и заказчиком и это великолепно работает в куче фирм.
На моём опыте, пресловутое time-to-market в этих фирмах больше чем в тех, где программисты общаются с постановщиками задач напрямую. Даже просто задержки на коммуникации снижают скорость разработки, не говоря об эффекте испорченного телефона.
А это что:
Для меня это минимально необходимые проверки. Написал код — проверил, что он вообще не ложит сервер в основных сценариях. Тестировщики уже проверяют полностью, но, блин, смержить в общую ветку код, который ты даже не пробовал запустить…
Но нельзя ожидать таких умений от каждого разработчика.
Вроде как это базовые компетенции программиста, определённые даже в профессиональных стандартах. Ему же не продавать что-то заказчику надо, а выпытывать у него, а что собственно он хочет.
Угу, и если заказчик всё-таки нашёл баги, то никто не виноват?
А если штатные тестировщики нашли баги, то кто виноват?
Ну у нас такого нет
У вас это где, если не секрет?
«Штатные тестировщики». Потому что это их зона ответственности.
Значит заказчик виноват. Потому что это его зона ответственности при такой работе.
Так как конкретно это всё определено в профстандартах...?
Российский, например https://classinform.ru/profstandarty/06.001-programmist.html. Можно по странице поискать по слову "согласование"
В вакансиях обічно такое не пишут, но в сильно бюрократизированніх организациях требуют соответствие образования — диплом предполагает наличие соответствующих знаний и хотя бы базовых навыков
То есть в такой ситуации для программиста не будет никаких последствий? Почему-то я в это не верю…
Когда работал так, то последствия были обычные для нахождения багов. Не важно кто и когда нашёл.
Я там нахожу только «согласование сроков». Я не так ищу?
Согласование требований к программному обеспечению с заинтересованными сторонами
И откуда тогда я должен знать что конкретно от меня требуется?
В хорошей вакансии прописано что-то вроде "участие в сборе требований" или "непосредственное взаимодействие с представителями заказчика". Иначе расскажут на собеседовании. Я так в обязательном порядке спрашиваю подобные вещи — как процессы построены, с кем, как и когда обязательные взаимодействия, с кем могу инициировать сам без нарушения субординации и т. п.
Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)
Потому что многие люди не хотят/не могут выходить из зоны своего комфорта. Но это не проблемы бизнеса, а этих людей. Для того, чтобы что-то найти (деньги, людей, процессы, и т.д.), то нужно это искать. А тот, кому хорошо и так, без этой вечной суеты, остаются за бортом возможностей. Люди ушли из проекта. Кто-то на бенч, кто-то в другие проекты. Кого-то потом уволили, после пары негативных отзывов от другого заказчика (вообще очень частый случай). На аутсорсе «отсидеться» не получится — это я гарантирую на 100%.
Отвечая на ваш вопрос, то такого спеца просто выгонят на мороз. А при устройстве в следующую контору, если у него мозгов хватает, то он будет говорить, что сам ушел, так как вырос. А если начнет понисить старое место работы, то и новое не найдет, так как токсичные и неадекватные люди никому не нужны.
А если, вдруг, какой-то компании позарез нужен будет высококвалифицированный специалист здесь и сейчас, то искать на улице никто не будет. Его схантят с другой работы с зарплатой + 1 тыс. долларов, вот и всех делов-то.
Ну и последний момент: «Нет такой профессии, как хороший парень». Если сотруднику что-то не нравится, то он вправе найти более подходящее место работы. Тут уже вопрос в том, что такие люди не будут получать высоких зарплат. А тот, кто хочет иметь высокий доход, тот будет идти в ногу с заказчиком, ради заказчика, и для заказчика и соответственно, проекта. По другому не бывает.
А вот менять правила игры по ходу это на мой взгляд не дело.
Нормальная ситуация, настолько нормальная, что даже в трудовом законодательстве прописана. Особенно если декларируются agile подходы изначально, где изменения правил игры неотъемлемая часть процессов. Нет изменений — нет agile.
А тут вы думаете другая ситуация? На улицу в мороз перед Новым годом? )
Зависит от того как работники себя повели. Некоторые, мягко говоря, фирмы не горят желанием напоминать работникам об их правах при существенном изменении условий труда.
В принципе в такой ситуации я для себя, как для работника, считаю необходимым минимумом обычную процедуру увольнения по собственному после того как нашёл новый проект, но в случае доверительных отношений с руководством, предупреждаю, что новые условия для меня неприемлемы скорее всего, и я начинаю искать новый проект, а когда найду отработаю две недели. Об отступных и прочих правах не заикнусь, если меня тут же не попытаются уволить.
То есть никаких? Или какие?
Какие-то есть, конечно. Вплоть до увольнения, если даже простейшую задачу не можешь сделать без десятка багов.
Тогда почему в данном конкретном случае кто-то ушёл когда «поменялись правила»? :)
Некоторые компании или, скорее, нанимающие менеджеры используют в вакансиях фразы типа "общение только внутри команды" или "общение только с лидом/ПМ" как продающие для людей определённого склада, с которыми им эффективней работать. Пришёл новый менеджер, изменил условия и работа перестаёт быть привлекательной. Человек может и может делать что-то от настройки локального дев-окружения до переговоров с заказчиком, но не хочет. И есть места, где он этого может не делать. Вот и уходит туда. А кто-то другой наоборот, целенаправленно идёт туда, где будет общаться с бизнесом напрямую.
Во первых надо отметить, что достаточно хорошо описана автоматизация процесса. Что, куда, когда отмечает, деплоит и прочие технические моменты.
Но вот когда дело доходит до субъективщены, тут все очень и очень плохо.
К примеру, возьмем самое начало.
Каждая задача должна быть максимально описана, и выполнять строго одно действие
Максимально описана, это как? Как по мне, в идеале это прямо код или в крайнем слечае псевдокод. Но я сильно подозреваю, что зачастую в описании используются подразумеваемые особенности (но которые в коде все равно отражаются), типа если добавляем кнопку, то не указываем, что вид у нее стандартный для проекта и подобное.
Любая фича, если она достаточно сложная, разбивается на много мелких тасок
А какая фича сложная? По времени реализации, по числу задействованных людей, по необходимым усилиям что бы эту фичу вообще придумать как делать? Ну и, естественно, отсюда вытекает невозможность адекватно поделить ее на мелкие.
Ну и т.д. Нет, я понимаю, что с точки зрения автора этих описаний достаточно (в голове-то они в каком-то виде есть), но воспользоваться ими в случае замены тимлида на кого-то другого (или внедрить в другой команде) будет достаточно проблематично.
Еще не указана численность и состав команды, а это очень важно, что-то будет хорошо работать в малом коллективе, что-то в большом. Кроме того, нужно было сразу и отдельно указать особенности взаимодействия с заказчиком. К примеру, я не понял, есть ли вообще выделенные тестеры в команде? Или может они есть у заказчика? Непонятно.
Кроме того, вся статья пронизана мыслью «у нас нет аналитика!», что, по большому счету, не очень-то хорошо. Отсюда прыжки задач от исполнителя к заказчику, общение исполнителя непосредственно с заказчиком и т.д. По всей видимости, по большей части аналитиком работает тимлид, но и на обычных программистов приходится немалая часть.
Непонятны еще такие моменты:
Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня.
На митинге тимлид также озвучивает об всех изменениях в проекте и об уровне текущих багов, которые были найдены не заказчиком. Все баги разбираются и назначаются на каждого члена команды для их решения.
Разработчики в первую очередь выполняют приоритетные задачи.
На митинге тимлид назначает на каждого задачи
Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.
Тот кто выполнял задачу сразу же трекает свое время для этой задачи
Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня.
Каждый день разработчик должен в чате клиента писать о том, над какими задачами он работал вчера и над какими задачами будет работать сегодня
Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?
Максимально описана, это как? Как по мне, в идеале это прямо код или в крайнем слечае псевдокод. Но я сильно подозреваю, что зачастую в описании используются подразумеваемые особенности (но которые в коде все равно отражаются), типа если добавляем кнопку, то не указываем, что вид у нее стандартный для проекта и подобное.
Например, есть задача: отправку напоминанию клиенту, что нужно оплатить инвойс. Обычная постановка задачи так и звучит, что нужно сделать такую фичу. И тут возникает ряд вопросов. А отправлять напоминание нужно один раз или много? Если много, то с каким промежутком? А напоминать через мыло или еще и через СМС, вебсокеты и т.д.? А если клиент так и не заплатил, то что делать с этим, до конца дней присылать уведомления? А если нужно останоить рассылку, то при каких условиях? Без ответов на эти вопросы не возможно четко выполнить поставленную задачу. Вот поэтому и нужно подробно описать заказчику, что нужно делать. Если он этого не может сделать или толково объяснить, то я созваниваюсь с заказчиком и мы все это обсуждаем. Я создаю флоу и кидаю на утверждение.
А какая фича сложная? По времени реализации, по числу задействованных людей, по необходимым усилиям что бы эту фичу вообще придумать как делать? Ну и, естественно, отсюда вытекает невозможность адекватно поделить ее на мелкие.
Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки. Системы рассылки, система заказов, платежная система и т.д. — это все сложные фичи. По факту это даже не сторисы а эпики.
Здесь отобразить кнопку сохранения данных, тут выводить какое-то агрегации и т.д. — это простые фичи, которые можно сразу осознать и понять, как их сделать. При этом потратив на них минимум времени.
Еще не указана численность и состав команды, а это очень важно, что-то будет хорошо работать в малом коллективе, что-то в большом. Кроме того, нужно было сразу и отдельно указать особенности взаимодействия с заказчиком. К примеру, я не понял, есть ли вообще выделенные тестеры в команде? Или может они есть у заказчика? Непонятно.
Изначально на проекте было 8 человек. 1 ПМ/аналитик, 1 QA 4 бэкендера и 2 фронтендера. В итоге сроки посрочены, работа топталась на месте, все искали виновных, проект замер. Клиент стал зверствовать и почти всех поувольнял. В итоге, осталось всего 3 человека. Я (пишу и бэк и фронт, выполняю роль и системного аналитика и архитектора, скрам тоже на мне), один бэкендер сениор и один фронтендер сениор. Перформанс увеличился раз в 10! Клиент теперь спокоен, как удав. Затраты уменьшились в разы, скорость увеличилась на порядок.
Так кто назначает задачи? Каждый сам планирует что делать? Может раздает тимлид? А вообще есть ли в этом смысл, если нужно брать следующую по приоритету? В общем пункты друг другу немного противоречат.
Все бизнес задачи создает заказчик. Но прилетают они все на меня. Я все их просматриваю и назначаю на людей. Каждую новую задачу мы обсуджаем на митинге. Я тоже создаю задачи, когда вижу в этом необходимость (изменение бизнес логики, рефакторинг, фикс багов, которые я нашел и т.д.).
Если все трекается, то какой смысл говорить о том, что сделано и делается? Кому интересно, может открыть жиру и посмотреть, кому не интересно, тот мимо ушей пропустит (вот я, к примеру, всегда так делаю :) ) Ну и зачем разрабу отписывать в чате чего сделано? Бота нельзя настроить, если уж заказчик по каким-то причинам не может пользоваться жирой?
Жира — это всего-лишь инструмент с кучей флагов. На каждом митинге мы всегда в курсе всего процесса работы. Фронтендер четко знает, что творится на бэке. Бекендер все знает о фронте. Так как на фронте юзается Реакт, то сам фронтендер в отрыве от бэкенда ничего не сможет сделать и наоборот. Создание одной конкреной фичи — это когда и бэк и фронт синхронно работают над одной задачей, чтобы превратить это в законченный кусок функционала. А так как мы еще юзаем кучу «хайповых» технологий и с десяток дополнительных АПИ сервисов, то не знание всего проекта целиком для кого-либо на проекте подобно смерти.
Что касается отпусков, то уже все, и я в том числе, уходили в отпуска не раз. Здесь вообще нет никакой проблемы. Все об отпусках договариваются одновременно. Мы составляем план релиза с учетов этого обстоятельства.
А по факту самого процесса программирования, то мы тратим процентов 70 нашего времени именно на дискуссии, обсуждение бизнес логики, архитектуру и планирование. И только 30% на сам кодинг. В итоге мы успеваем все, так как ничего не приходиться по десять раз переделывать.
Это в общем-то не сложно, та же самая аналитическая работа. Как говориться тыжпрограммист :)
Любая фича сложная, которая не может быть самостоятельно закрыта одним разработчиком в относительно короткие сроки.
А если фича может быть закрыта одним программистом, но не в короткие сроки?
А если не одним, но в короткие?
А короткие это сколько?
А почему именно столько?
Ну и так далее до измеримых величин.
Перформанс увеличился раз в 10!
Ну дык это еще в мифическом человекомесяце было отмечено, что увеличение команды скорость разработки не увеличивает :)
А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.
А с 70% чет мне на вскидку кажется перебор. Но может это ваша специфика, не мне судить. Но почти наверняка при увеличении команды эффективность оооочень сильно просядет.
Причём эффективность обсуждений прежде всего. Банально большее число точек зрения будет высказано, а времени на обсуждение плюсов и минусов останется меньше. Но есть возможный выход: текущую команду попробовать превратить в "архитектурный комитет" и набрать кодеров.
Можно только порадоваться, что у вас все получилось. Такие истории успеха часто слышу от работающих с иностранными заказчиками — у них другая культура и понимание, что подход "надо все переделать и сделать это надо было ещё вчера" не работает.
Простите, а зачем разработчику, техническому специалисту, тратить уйму времени на общение с заказчиком? Разве не целесообразней потратить его на разработку? А общаться с заказчиком может кто-угодно, менеджер например.
Организация рабочего процесса в команде на IT-проекте