Techleads meetup в офисе Badoo

Макс Лапшин

Erlyvideo

Как создать небольшую и прибыльную софтверную компанию, если ты программист?

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

Буду говорить о том:

1. как мы планируем разработку софта, который потом продается в 100 странах мира. Что делаем сейчас, что потом и что делаем с тем, что не получается сделать.
2. что мы делаем, чтобы не устраивать себе ежедневный стресс? Специфика продуктовой разработки, которая очень далеко от конечных пользователей и принципиально не тестируется in-house в полной мере.
3. как мы упрощаем свою работу, чтобы двигаться вперед, сохраняя низкий уровень стресса.

Что получается, а с чем плохо справляемся.

Евгений Потапов

ITSumma

Техническая поддержка сайтов как бизнес: люди, управление, процессы

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

1. Кадровые вопросы:
– как найти и обучить нужных людей
– специфика сменной работы
– обмен опытом и знаниями в команде

2. Управление процессом:

– специфика постановки задач, связанных с поддержкой и оперативным реагированием
– планирование в условиях хаотической смены приоритетов

3. Мониторинг техподдержки как средство минимизации человеческого фактора:

– обработка входящих запросов
– мониторинг времени, затраченного на выполнение задач
– организация и автоматизация "бэк-офиса".

Алексей Рыбак

Badoo

Performance Review на страже ценностей в динамичной компании

Многие инженеры нервно кривят лицо, когда слышат слова «оценка производительности работы». Кто-то вспоминает слухи о разнарядкях Microsoft, кто-то – бессмысленные длиннющие формы, которые приходится заполнять раз в год по указке сверху.

Менеджерская мутотень! 

Инженеров нельзя измерить, ревью только мешают!

KPI для инженеров не работают, только раздражают!

Всё это можно услышать во время обсуждения performance review и, наверно, во многих случаях это сущая правда.

Badoo – инженерная компания, и, конечно, мы не родились с performance review. Наше первое знакомство случилось давно, когда нам было, кажется, лет шесть. Тогда в нашей компании был старший товарищ, который уже имел дело c performance review, и он уговорил нас попробовать. Мы решились, убеждая себя: «Ну, один или два раза. Всегда сможем остановиться».

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

В этом докладе расскажу:

* о простых правилах успешного ревью;
* как мы создавали и внедряли сам процесс;
* с какими проблемами столкнулись и как их решаем;
* нужен ли вообще вам review.

Илья Пятин

CarPrice

Как менялись процессы в IT, когда компания в течение двух лет росла на 20% каждый месяц

В своём докладе я хочу рассказать о том, как эффективно меняется структура и процессы в IT во время роста компании. Два года подряд я каждый месяц приходил в “новую” компанию, которая была на 15-20% больше, чем та, где я работал месяц назад. Постоянно запускались новые проекты, эксперименты, а иерархия и схема разработки месячной давности уже не подходили для CarPrice нового образца, и их приходилось менять, чтобы не снижать темп. Я собираюсь рассказать об эволюции процессов и инструментов, а также о тех вещах, которые успешно прошли с нами через все эти этапы развития.

Поговорим о:

1. Что делать, когда твоя компания – эксперимент?
2. Что делать, когда твоя компания внезапно перестала быть экспериментом?
3. Как быстро масштабировать среду и окружение для разработки;
4. Как быстро набирать программистов в команду, чтобы потом они не отваливались;
5. Управление: от пары разработчиков до большого департамента;
6. Подход к системной архитектуре и внедрению экспериментов.

Андрей Шелёхин

Tinkoff.ru

Вжух, и у вас Agile!

Вам хочется построить качественный процесс разработки. Кажется, что вокруг масса источников, которые в этом помогут. Например, книги по Agile и Scrum, объясняющие, что же на самом деле написано в 17-ти страничном Scrum Guide; тренинги, которые наконец-то объяснят вашим негибким разработчикам про целебные свойства доски со стикерами, что story point-ы лучше идеальных часов, и как наказывать опоздавших на Daily Meeting.

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

Есть помощь другого рода – внешний консультант. Он готов ежедневно работать с командой, пока каждый из участников не научится объяснять разницу между Agile и Scrum, умещать User Story на стикере и рассказывать, как прошел предыдущий день. Но и внешний консультант не гарантирует вам успеха. Свяжетесь не с тем – сделаете только хуже и просто потеряете время и деньги.

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

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

- О чем забывают руководители разработки?
- Можно ли с помощью процессов решить проблемы в разработке, не создав помех бизнесу?
- Как нарушать правила, описанные в книгах про Scrum, и не винить себя за это?