Комментарии 9
Его задачи: аналитика требований бизнеса
Не очень понятно — он что бизнес-аналитик? Или ему спускают готовое ТЗ (описание) и он анализирует именно это описание, чтобы разбросать по технической части?
Отдельно скажу о саппорте: его флоу управляют менеджеры, которые взаимодействуют со складом, а выполняют дежурные разработчики.
А можно тут подробней рассказать? В саппорт прилетают различные вещи и для начала их надо идентифицировать (это бага, это надо инструкцию обновить, это мелкая доработка, это похоже на эпик, это пользователь тупой). И ведь кто-то этим должен заниматься. Таким образом, разработчикам будет уходить только часть этих тикетов. Мало того, порой непонятно бага это или фича и требуется время разработчика, чтобы глубже копнуть. А такие задачи кому уходят? Дежурным? Да и еще — бывают такие тикеты, что без поллитра не обойдешься, нужно еще привлечь бизнес-аналитиков и созвониться с пользователем.
И еще не понятен жизненный цикл feature команды в рамках проектов. Они что сделали проект и свалили (распались)? А кто поддерживать будет?
Не очень понятно — он что бизнес-аналитик? Или ему спускают готовое ТЗ (описание) и он анализирует именно это описание, чтобы разбросать по технической части?
Тут слово «бизнес» использовано в довольно широком смысле: на стороне нашего заказчика (склада) есть отдельное организационная структура, которая отвечает за развитие технических процессов. Они являются «мостиком» между стейкхолдерами и командами разработки. На фазе анализа нового проекта или отдельной user-story они выясняют формальные требования, разрабатывают и описывают подход к решению на уровне бизнес-процессов. Кстати говоря, их функции не сводятся только к бизнес-аналитике: например помимо прочего они занимаются сопровождением внедрения.
Именно с этой командой в первую очередь взаимодействует техлид проекта — вместе они уточняют подход и прорабатывают детали с учетом понимания технической стороны вопроса, которе есть у техлида.
После этого техлид формирует пулл задач и начинается разработка.
А можно тут подробней рассказать?
Дежурные разработчики, разумеется, не выполняют роль первой линии поддержки. Проблемные ситуации сначала проходят через системных администраторов склада и/или через команду, отвечающую за развитие технических процессов, о которой я написал выше. На этом этапе отсекаются такие не относящиеся непосредственно к софту вещи как незнание должностных инструкций, проблемы с оборудованием и т.п.
Если первой линии решить проблему не удалось, задача попадает к нам: дежурный разработчик анализирует ситуацию с помощью логов, SQL запросов и кодовой базы.
В случае если проблема идентифицирована и имеет малый масштаб, ее правит сам дежурный либо в коде, либо отдав на выполнение соответствующий SQL скрипт, либо просто передав что надо сделать в рамках бизнес-процесса.
Если и у дежурного разобраться не получилось, либо речь идет о крупной проблеме, задачу как правило посмотрит тимлид, при необходимости привлекая техлида направления, менеджера и команду склада. В этом случае как только становится ясно, что именно нужно сделать, задача передается обратно дежурному разработчику.
И еще не понятен жизненный цикл feature команды в рамках проектов.
Речь не идет о некоем абстрактом пуле, из которого под проект выделяются разработчики и в который они попадают обратно после завершения.
В нашем случае этот пул — как правило команда, тимлид которой является техлидом проекта.
Завершив разработку, ее члены участвуют в сопровождении внедрения и параллельно начинают смотреть текущие задачи, либо сразу приступают к новому проекту.
Эта команда существует постоянно, проводит стендапы, ретро и прочие активности.
Если позже будет найден специфический для этого проекта баг, с которым не сможет справиться дежурный разработчик при сапорте, то задача попадет к техлиду(тимлиду), который доопишет ее и передаст одному из участников проекта.
проекты, над которыми работает каждая команда, связаны между собой? или это полностью отдельные фичи?
достаточно ли такого количества qa для нормальной проверки всего, что понаписано?
проекты, над которыми работает каждая команда, связаны между собой? или это полностью отдельные фичи?
До недавнего времени наше основное приложение было монолитом, который сопровождали несколько клиентов: веб, мобильный, мониторинги для менеджмента. Поэтому при выполнении проектов команды работали с общей кодовой базой.
В то же время, поскольку отдельные user-story, небольшие и средние проекты как правило затрагивают только один операционный процесс (которых на складе достаточно много), значимого влияния друг на друга они не оказывали как при разработке, так и после внедрения.
Этому также способствовало то, что во всей кодовой базе монолита мы стараемся придерживаться единообразия в архитектурных и технических решениях: изобретать велосипеды, которые могут что-то серьезно сломать в системе в целом, обычно нет повода.
Сейчас в связи с разделением основного приложения на отдельные модули-сервисы (об этом недавно была статья на нашем хабе) и закреплением их за отдельными командами, мы ожидаем что соблюдать такое разделение при сохранении единообразия будет сложнее как на уровне кода, так и на уровне внутрикомандных процессов и межкомандных взаимодействий. Возможно, что по итогам мы поделимся новым опытом :)
достаточно ли такого количества qa для нормальной проверки всего, что понаписано?
В нашей работе был период, когда состав разработчиков уже расширился до целевого на тот момент, а QA за ним не поспели — образовалась внушительная очередь из задач на проверку.
В конечном итоге ее разобрали и сейчас, при очередном расширении штата, мы уже нацеливаемся на соотношение между QA и DEV, близкое к 1:2
Ожидаем, что такого соотношения будет достаточно как на ручную проверку нового функционала, так и на увеличение покрытия автотестов — сейчас на последнее действительно не хватает времени.
Спасибо за эту фразу. За 20 с лишним лет работы я не встретил конторы, которая это осознаёт. Но подозревал, что они есть.
Рад, что в вас эта мысль отозвалась :)
Однако справедливости ради, думаю что подойдя к менеджеру любой организации и спросив, согласен ли он с ней в принципе, мы услышим положительный ответ.
Другое дело что управление разработкой, как и любое другое управление, в конечном счете является пресловутым «искусством возможного». Если, например, стоит задача в короткие сроки сделать проект, передать результат заказчику и забыть про него, я как менеджер буду осознавать, что такие вопросы как выстраивание специфичных процессов, контроль за эмоциональным выгоранием сотрудников и текучкой кадров разумеется важны, но не критичны в данный момент. Всем этим можно озаботиться «потом», а «сейчас» главное в срок поставить сносный продукт. В конце концов и кадры — не «лучшие из лучших», и тот же самый SCRUM уже давно придумали и во многих местах успешно (в той или иной степени) применяют.
И как бы цинично это ни звучало, думаю что такой подход в конкретной ситуации вполне оправдан.
В нашем случае ситуация иная. Кодовая база системы находится в разработке более 8 лет, постоянно меняясь и расширяясь вместе с процессами на складе. В такой ситуации просто нет иного выбора, кроме как с одной стороны методично отстраивать процесс разработки и внедрения и быть готовыми адаптировать его под конкретную ситуацию, а с другой — заботиться о том, чтобы разработчикам было комфортно делать свою работу. В противном случае она может в какой-то момент превратиться в хаос, и не будет людей, способных и желающих хранить и передавать знания о технических особенностях всех составляющих систему процессов. А это критично в ситуации, когда пропущенный баг потенциально может заблокировать работу целой секции склада и сотни людей через 10 минут после очередного релиза.
Конечно при работе в таком режиме есть свои челенджи, но я бы сказал что оно того стоит :)
Однако справедливости ради, думаю что подойдя к менеджеру любой организации и спросив, согласен ли он с ней в принципе, мы услышим положительный ответ.
Другое дело что управление разработкой, как и любое другое управление, в конечном счете является пресловутым «искусством возможного». Если, например, стоит задача в короткие сроки сделать проект, передать результат заказчику и забыть про него, я как менеджер буду осознавать, что такие вопросы как выстраивание специфичных процессов, контроль за эмоциональным выгоранием сотрудников и текучкой кадров разумеется важны, но не критичны в данный момент. Всем этим можно озаботиться «потом», а «сейчас» главное в срок поставить сносный продукт. В конце концов и кадры — не «лучшие из лучших», и тот же самый SCRUM уже давно придумали и во многих местах успешно (в той или иной степени) применяют.
И как бы цинично это ни звучало, думаю что такой подход в конкретной ситуации вполне оправдан.
В нашем случае ситуация иная. Кодовая база системы находится в разработке более 8 лет, постоянно меняясь и расширяясь вместе с процессами на складе. В такой ситуации просто нет иного выбора, кроме как с одной стороны методично отстраивать процесс разработки и внедрения и быть готовыми адаптировать его под конкретную ситуацию, а с другой — заботиться о том, чтобы разработчикам было комфортно делать свою работу. В противном случае она может в какой-то момент превратиться в хаос, и не будет людей, способных и желающих хранить и передавать знания о технических особенностях всех составляющих систему процессов. А это критично в ситуации, когда пропущенный баг потенциально может заблокировать работу целой секции склада и сотни людей через 10 минут после очередного релиза.
Конечно при работе в таком режиме есть свои челенджи, но я бы сказал что оно того стоит :)
Как заголовок статьи вяжется с сеньëрами, которые в нерабочее время, приходят на помощь?
Заголовок призван отразить одну из основных идей статьи, в которой идет речь о наших процессах: систематические переработки не входят в список требований к сотрудникам и в большинстве ситуаций не приветствуются; наоборот — мы стараемся создавать такие условия, чтобы в них не было необходимости.
Разумеется, режим работы заказчика 24/7/365 предполагает, что от команды может потребоваться сапорт во внерабочее время. В конце концов, мы ответственны за работоспособность собственного продукта.
Но тут следует подсветить несколько моментов:
— в отличие от дежурств в рабочее время, вхождение в пулл сапорта во внерабочее время не является обязательным: оно опционально и разумеется отдельно оплачивается;
— люди входят в этот пулл в первую очередь не по грейду, а по уровню знания системы и опыту: синьор или тимлид со стажем год-полтора в него попасть не сможет;
— прочие процессы построены так, чтобы число ситуаций, когда сапорт во внерабочее время действительно необходим, было сведено к минимуму: кейсы когда такая необходимость возникает чаще 1-2 раз в неделю очень редки, а зачастую обходится и без них.
Повторюсь, что основной лейтмотив статьи в отношении переработок состоит в том, что мы стараемся выстраивать процессы так, чтобы эти переработки не являлись значимой и тем более обязательной частью всей системы.
Пройдясь по истории коммитов в основном репозитарии, конечно можно найти такие, которые были сделаны в 2 ночи или 5 утра. Но такого режима от разработчика никто не требует, а если он является систематическим — есть повод обсудить это с человеком.
В конце-концов, поскольку мы находимся в хороших отношениях с бизнесом, в подавляющем числе ситуаций перенести (разумеется приведя основания для этого) очередной майлстоун проекта — более приоритетное решение, чем стимулировать эмоциональное выгорание команды.
Разумеется, режим работы заказчика 24/7/365 предполагает, что от команды может потребоваться сапорт во внерабочее время. В конце концов, мы ответственны за работоспособность собственного продукта.
Но тут следует подсветить несколько моментов:
— в отличие от дежурств в рабочее время, вхождение в пулл сапорта во внерабочее время не является обязательным: оно опционально и разумеется отдельно оплачивается;
— люди входят в этот пулл в первую очередь не по грейду, а по уровню знания системы и опыту: синьор или тимлид со стажем год-полтора в него попасть не сможет;
— прочие процессы построены так, чтобы число ситуаций, когда сапорт во внерабочее время действительно необходим, было сведено к минимуму: кейсы когда такая необходимость возникает чаще 1-2 раз в неделю очень редки, а зачастую обходится и без них.
Повторюсь, что основной лейтмотив статьи в отношении переработок состоит в том, что мы стараемся выстраивать процессы так, чтобы эти переработки не являлись значимой и тем более обязательной частью всей системы.
Пройдясь по истории коммитов в основном репозитарии, конечно можно найти такие, которые были сделаны в 2 ночи или 5 утра. Но такого режима от разработчика никто не требует, а если он является систематическим — есть повод обсудить это с человеком.
В конце-концов, поскольку мы находимся в хороших отношениях с бизнесом, в подавляющем числе ситуаций перенести (разумеется приведя основания для этого) очередной майлстоун проекта — более приоритетное решение, чем стимулировать эмоциональное выгорание команды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы позволяем разработчикам разрабатывать, а не перерабатывать