Главное Свежее Вакансии Образование
Выбор редакции:
😼
Выбор
редакции
653 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как подружить разработку и бизнес

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

Рассказывает Алексей Катаев, руководитель разработки в Skyeng и автор канала Тимлид Леонид.

b_5cff5b34ca8dc.jpg

Несколько примеров. Допустим, мы делаем попап и эта задача занимает всего 4 часа. Но потом нужно сделать какую-то кнопочку, которой у нас нет в UI ките, и мы тратим еще полтора дня на эту кнопку. Задача оказывается в продакшене через два дня вместо шести часов. Другой вариант – разработчик делает задачу за 4 часа, отправляет её в тестирование и QA присылает ему 20 багов. Он начинает фиксить эти баги и выясняется, что 10 у него не воспроизводится, 10 он пофиксил, а они потом все равно воспроизводятся у QA. На работу с багами уходит два дня. И третий пример, знакомый всем – человек отправляет pull request и получает 50 комментариев: "Всё плохо, все нужно переписать". Он начинает переписывать, спорить, тратить время.

Как мы оптимизировали эти процессы в Skyeng, как мы нашли баланс между требованиями бизнеса и стремлениями разработчиков?

Хорошее решение – простое решение

b_5cff8e0f66519.jpg

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

Что мы делаем, чтобы не тормозить процесс на этом этапе?

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

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

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

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

Как улучшить техническое ревью?

b_5cff8e1fe4d2c.jpg

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

Мы это всё поменяли и теперь каждую задачу у нас обсуждают только те разработчики, которые либо разбираются в этой области, либо хотят начать разбираться. В каждом техревью участвует максимум 3-4 человека. Один из них – тимлид, который должен быть в курсе всех технических решений. Мы постим в канал все задачи (вместе с необходимой документацией, чтобы не тратить время и заранее подготовиться к встрече) и голосуем, какие задачи мы хотим обсудить. В итоге на решение сложной задачи у нас уходит полчаса, тривиальные решаются за 10 минут.

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

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

Баг или не баг?

Какая у нас проблема в QA? Мы сделали задачи, они нашли много багов. Что дальше? Делать совсем без багов? Нереально. Тестить своими силами? Мы этого не хотим.

У нас для QA тоже есть чеклист для багов (мы чеклисты вообще любим). Сколько пользователей аффектит этот баг? Если пользователей у нас 100 тысяч, а проблема – только у одного, мы просто не обращаем внимания. Исправление проблемы будет дороже, чем ее воздействие на процесс. Трудно ли воспроизвести баг? Например, QA пишет: "Я переключал слайды туда-сюда и ткнул на поп-ап, и он у меня как-то криво открылся". Вероятность воспроизведения этого бага в реальных условиях –– почти нулевая. Каков шанс, что пользователь будет вот так тыкать между слайдами? Значит, мы не будем это фиксить, это лишено смысла. Точно ли это баг? Не все то, что QA и мы воспринимаем, как баг, это на самом деле баг. Кнопочка чуть-чуть не в том месте. Кнопочка чуть-чуть не того цвета. Да какая разница? Пользователь даже не поймет, что это баг, это никак не повлияет на его взаимодействие с продуктом.

b_5cff8e2faa9d9.jpg

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

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.