Профессионализм.
Разница в эффективности между хорошим и посредственным таксистом, пожалуй, 30%. Разница между хорошим и посредственным программистом — тысячи процентов. Хорошие разрабы сэкономят вам много времени и денег. Не все должны быть звездами, но костяк команды — должен.
Проактивность.
Современный стиль создания продукта — глубокая вовлеченность каждого в процессы. Разработчики должны понимать продуктовые задачи, дизайнеры — технические ограничения и т.п. Если человек пассивный и хочет «писать код в уголке», ему органически будет сложно работать.
Честность.
Если вы постоянно что-то обсуждаете, сообща решаете проблемы, страхуете друг друга — обязательно кто-то где-то накосячит. Это не страшно, если об этом честно говорят. Честность помогает работать и помогает увольняться. Решил уйти — скажи заранее.
Постоянные изменения.
Залог здоровья команды — постоянные изменения. Я предпочту команду с кучей проблем, которая регулярно проводит ретроспективы и выполняет их решения. Чем команду, в которой все хорошо, но которая не проводит ретро и не меняется.
Человечность.
Приятно работать с людьми, которые знают о твоих увлечениях и достижениях твоих детей. Мы всё же люди, а не боевые юниты.
Юмор.
Наш IT-директор раньше был офицером на флоте. Рассказывал, как у них были учения, где их всем штабом отправляли в бункер на неделю. Делать там было особо нечего, если бы не шутки, сошли бы с ума. В командах разработки что-то подобное. Хотя дел много, но без юмора тоже никак
Безопасность.
Хорошая команда — это почти семья. Люди разные, случаются и конфликты. Но важно, чтобы все чувствовали себя безопасно. Должна быть гарантия, что тебя не унизят, не подставят, не будут сплетничать за спиной.
Как железо оттачивает железо, так и люди совершенствуют друг друга.
Притчи 27:17
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Плохой команду делают: непрофессионализм, инфантилизм, апатичность, лень, неправильный фокус, ссоры, боязнь конфликтов. Что-то одно у кого-то одного — уже плохо. Ниже разберем подробнее. Беру из моего личного 20-летнего опыта.
Непрофессионализм.
Если разработчик плохо программирует, его не спасет то, что он отличный парень. Точнее, это еще хуже. Свой первый продукт я написал со старинным другом. После первых продаж оказалось, что код написан так плохо, что его уже не спасти. Продукт пришлось закрыть.
Инфантилизм.
Я работал со взрослыми парнями, у некоторых были жены и дети. Они часто пошло шутили над единственной девушкой в команде. Могли долго ржать над фамилией иностранного коллеги. Это была не грубость, а поведение школьников-старшеклассников. Здорово утомляет и раздражает
Итак, ответим на частый вопрос: «Как вы проверяете фичу»? Ответ: «Головой». К сожалению мне не известен универсальный алгоритм для проверки эффективности фичи. Все фичи разные, и анализировать их надо по-разному.
Технически я проверяю фичи через GA ивенты. На этапе прототипа, пишу задание разработчикам. В GA есть вложенные сущности: категории, экшны, лэйблы, вэлью. Если все действия в продукте обвешать правильно написанными ивентами, анализировать поведение пользователя будет легко.
К примеру, вот GA ивент при отправке поискового запроса (в фигурных скобках — переменные):
Довольно частый вопрос: «Как вы проверяете фичу»? Мне кажется, что прежде всего надо проверять не каждую фичу, а продукт в целом.
Статистика по продукту должна собираться автоматически и отображаться в легком для интерпретации виде. Зашёл на дашборд, посмотрел, всё понял. У меня есть дашборд с воронкой, дашборд с ретеншном, дашборд про деньги и т.п. А еще есть дашборд про быстродействие.
Старики говорят: «За двумя метриками погонишься — ни одну не улучшишь». Невозможно улучшать все продуктовые метрики одновременно. Лучше сосредоточиться на чем-то одном. Как минимум, в течение 2-3 месяцев. Например улучшать количество первых платежей. Или увеличивать средний чек.
ДЕМО — встреча в конце спринта, где мы показываем то, что сделали в спринте. Цель — получить фидбэк от всех заинтересованных лиц. Ну и конечно же похвастаться, какие мы молодцы.
Мы показываем фичи только на продакшене. Раньше многие команды выходили, показывали новую фичу на тестовом сервере и говорили «в понедельник выльем в прод». Проходило две недели, они опять выходил на демо, и оказывалось, что фича до сих пор не в продакшене.
Когда команд стало много, а стейкхолдеров еще больше, демо стало менее эффективным. На качественную обратную связь и вопросы не хватает времени. Поэтому сейчас для меня важнее написать в специальный чат о новой фиче.
РЕТРО, ретроспектива — встреча раз в спринт, где команда может выяснить отношения и позитивно поконфликтовать. Есть много прикольных фреймворков, как проводить ретро. Но мы пользуемся самым простым: плюсы, минусы, голосование, обсуждение, решения.
Мы проводим ретро так. Каждый пишет на стикерах «плюсы» — что хорошего было в спринте. По очереди наклеивает на доску и поясняет на словах. Потом тоже самое с «минусами». Плюсы не обсуждаем. Минусы обсуждаем и принимаем практические решения.
Все минусы не успеть обсудить. Поэтому каждый отдает свой голос за три самых важных на его взгляд проблемы. Начинаем обсуждать проблем, которые набрали наибольшее количество голосов. Стараемся сформулировать конкретные шаги, как решить проблему. Эти решения выписываем на доску.
СТЕНДАП (дэйли) — встреча на 15 минут, где каждый отвечает на вопросы: что делал, что собираюсь делать, какие есть проблемы. Проблемы не обсуждаются, а выносятся на парковку — реальную или виртуальную доску, где на стикерах записаны проблемы со стендапа.
Есть огромное желание начать обсуждать проблемы прямо на стендапе. Особенно, когда кажется, что решить их можно быстро. Не стоит этого делать, ведь у каждого выступающего есть всего полторы-две минуты. Лучше потратьте их на уточняющие вопросы.
Перейдя на удаленку, мы перестали видеться в офисе и решать мелкие вопросы между делом. Поэтому на парковке после стендапов скапливалось много проблем. Мы начинали их обсуждать после стендапа и делали это по часу. Стендап вроде 15 минут, а реально полтора часа.