Быть продактом тяжело. И не важно: делаешь ты веб-сайт, мобильное приложение, или же ремонт дома.
Это всегда какой-то продукт, ответственность за него. Это всегда люди, которые его делают. Это всегда ты, который пытается всё состыковать воедино, чтобы оно заработало, чтобы был нужный эффект.
Со всех сторон есть определённые обязательства, о которых думать тебе.
Опять же редко проекты бывают линейными, как в задачках по математике.
"Из пункта А в пункт Б едет поезд со скоростью Х. Определите время прибытия поезда".
Нет, у нас сотни поездов и первое, что надо продумать – как хотя бы всем поездам добраться до цели и не поубивать друг друга.
О чём речь?
Всем привет! Меня зовут Гоша, и я разработчик. До этого я работал тим-лидом с командой около 30 человек.
Это была интересная работа, когда тебе надо довольно быстро определить набор задач, раскидать их по людям, определить скорость, чтобы участки различных этапов разработки не конфликтовали между фичами, помочь с коммуникацией между разработчиками, доуточнить фичи у заказчиков, выбить время у тестировщиков, подпнуть людей пофиксить баги, переключившись с текущей фичи на старую, всё это дело задокументировать, презентовать окружающим, а потом ещё и оценить вклад каждого в финальный продукт.
Я определённо что-то забыл, но руководство это устраивало – с косяками, но всё же лучше, чем хаос, который был.
Интересный опыт. И первый совет: размер команды, с которой вы непосредственно работаете не должен превышать 9-ти человек. А лучше – 5. Уж 5 дополнительных контекстов в голове можно удержать. И это не моё ноу-хау, а распространённая рекомендация в зарубежном менеджменте и психологии.
Это был не первый опыт в управлении разработкой. Я несколько раз оказывался по разные стороны "баррикады". И с каждым разом мне она казалось всё менее и менее нужной и всё более и более мешающей.
Перед собой же я ожидаю увидеть людей, которые разрабатывают какие-то продукты, либо же планируют заняться этим непростым делом.
Куда мы идём?
Первый, на мой взгляд важный совет для project lead / product manager / team owner – планируйте всё!
Какой у вас план? Пятилетка? Год? Месяц? Спринт? Или же вы как великие – импровизируете, когда спросят? Какой вариант верный?
На мой взгляд, хороший вариант иметь все эти слои плана. И чем ближе срок исполнения мы можем иметь всё более чёткий и детализированный план.
Мало того, этот план должен быть известен команде, но даже опубликован. Такой подход позволяет планировать не только вам, но и разработчикам (в широком смысле – дизайнер или операционист call-центра – тоже разработчик!).
"Делай локально, мысли глобально" – это правда, многие разработчики могут заранее "сделать хорошо", чтобы в будущем было проще добавить запланированную фичу.
Но как же мы можем планировать на такие длительные промежутки, когда наш мир изменчив и меняется каждый день? Само собой изменчив! Но и планы можно корректировать.
*Вы не можете корректировать ваши планы, если у вас их нет!;
И да, корректировать не так уж сложно. Обычно всё меняется, но не кардинально.
Чётко осознавать текущее положение
Второй важный совет: знайте свой продукт! А есть ли у нас фича X? А что, если мы обновимся – мы потеряем данные пользователей в этот момент? Мы хотим подключить к сервису Y – что нам нужно? Там иногда бывают в пике 1000 запросов. Всё же нормально будет? А при росте через год? Я получил 418-ую ошибку – что делать?
Почему это важно? Я ведь могу спросить!
Как бы да, но нет.
Каждый глупый вопрос вытащит вашего разработчика из той пучины, в который он погрузился, чтобы влезть в другой контекст, чтобы дать все возможные ответы валидации и ошибок, которые можно оттуда достать. И вы будете последней сволочью, если не запомните их.
Мы же уже планируем – так ведь?
Мы не можем планировать куда двигаться, если не понимаете, где мы!
Дьявол кроется в деталях. Именно крайние случаи и "да потом доделаем нормально" и съедает больше всего времени команды.
Те люди, которые делают
Третий важный совет: знайте свою команду! А что любит Вася: рефакторить, добавлять фичи, фиксить баги, заниматься инфраструктурой или же помогать окружающим... Всё это важно, всё это может быть "козырной картой" вашего разработчика.
И да, мы тут планируем... Планируем то, что будут делать другие люди. А они имеют другое мнение. Добро пожаловать в реальный мир!
Эти ребята будут делать то, на что мы "подпишемся", что мы решим. О-очень неплохо бы расспросить их по фиче, узнать о возможных косяках... А они будут! О том, как согласуется план с текущим положением дел.
Да, вы это знаете... вы на самом деле думаете, что знаете... Нет, это не так!
Глупо набирать в команду профи и не пользоваться их мнением.
Начальники не нужны
Самый важный совет: Хозяина нет. И начальника нет. И руководителя нет.
Нет, правда. Ни начальника, ни менеджера, ни руководителя... Как вы ещё называете их?
Давайте вернёмся к "баррикадам" – вот мы ходим туда-сюда. Для того, чтобы великая воля начальника была интерпретирована тобой, чтобы стать твоей волей как начальника...
Вы ещё тут? Давайте поймём, что ещё важного делает "начальник".
Чем мы вообще тут заняты?
Вряд ли мы монополисты. Скорее всего, мы сосуществуем на конкурентном рынке. И самая большая для нас ценность – клиент.
Мы делаем клиентам хорошо за деньги.
– вот и всё. А кто действительно работает с клиентом? Оператор call-центра? дизайнер интерфейса? бекенд разработчик, который ведёт пользователя "из точки А в точку Б"?
Да, эти люди и делают "хорошо" пользователю.
Тогда где же "начальник", "руководитель", "product anything"? В какой момент, в какой точке менеджер делает хорошо клиенту?
Клиентом менеджера является команда, в которой он работает. Его задача – сделать хорошо команде, чтобы те могли делать хорошо клиенту.
Так кто начальник?
Как же так? Ведь мы – начальник... или нет? Все же должны делать "ку" 3 раза...
В мире, где клиент – главное, все процессы разворачиваются в сторону клиента. Тот, кто делает клиенту хорошо! – Ваша команда... И внезапно ваша команда – ваш начальник! Иначе говоря, подчинённые – это начальники начальника.
Всё перевернулось. Мир вверх дном... Или раньше так было? Сама терминология "начальник – подчинённый" теперь неэффективна и нелогична.
Что вместо этого?
Дизайнер рисует интерфейс, программист автоматизирует процесс, но всем им нужно понимание: каков же процесс сейчас, каким должен быть (как выглядит/как должен).
Дизайнер не является аналитиком, не держит в голове общую картину продукта – его задача качественно сделать часть продукта.
Программист не является исследователем, не занимается сбором бизнес-требований у всех "заинтересованных" лиц. Он берёт описанный процесс, автоматизирует его.
Этим занимается владелец продукта / руководитель проекта?
- Знает текущее состояние проекта, консультирование по проекту.
- Планирование развития проекта / продукта (сбор информации, общение с аналитиками и тд).
- Донести всю необходимую информацию до команды, получить и учесть мнения членов команды.
Наконец-то поняли свою роль? Исчез экзистенциальный кризис?
Как оно обычно бывает
Казалось бы, ведь всё это понятно и логично. И все красавцы и "котики"... Зачем вообще об этом говорить?
К сожалению, часто это не так. Вот несколько перлов от менеджеров продуктов:
У меня одна проблема с программистами – что их бить нельзя! Сначала тратят время на программу, потом им какой-то рефакторинг нужен, поддержка нужна. Зачем они тогда так пишут?
– человек пришёл из другой сферы, со старыми привычками. Понимать процессы он не хочет, а учитывать мнения других уже не может – считает, что все обманывают.
Привет, я не понимаю в программировании и этом бизнесе. Но я буду вам помогать со всем!
– не совсем понятно, какую помощь хочет предоставить человек. Но, видимо, хочет...
Да, это довольно красочные отбитые примеры. Часто, это не так видно. Для закрепления вот 2 "кривых зеркала", чтобы понять, где есть просадки, что задевает.
Крепкий хозяйственник
Это не самый ужасный, но заметный участник работы. Он когда-то программировал, временами занимался дизайном, понимает в тувиноском горловом пении... но абсолютно не понимает в современной разработке!
Довольно красноречиво о нём говорит такая фраза:
Ты оценил задачу в неделю. А тебе будет стыдно, если я её за день сделаю.
И делает. Делает небольшую начальную реализацию, которая работает в части случаев некорректно, не покрыта тестами, да и вообще не по процессу разработки – само собой, её невозможно ни выкатить, ни использовать.
Может начнём слушать людей? Спрашивать их, понимать реальные проблемы.
Передаст
Этого заметить не так просто. Да, он вечно занят и летает со встречи на встречу, на которых титаническими усилиями десятка людей, пытается ответить на вопрос: "а что делать с кнопкой сохранения?".
Продукт ему не близок, но он довольно неплохо общается с людьми. Передать / спросить / договориться о переносе сроков – вот, чем он занимается. В принципе, не плохо, пока не задаются вопросы, пока всё идёт нормально.
Часто можно встретиться с такими "товарищами". Такие могут неслабо нас оттянуть назад. Такие ребята любят всё переспрашивать и переговаривать, ибо своей позиции нет. Может такой быть лидером проекта?
Что делать?
Определиться со своими обязанностями, опубликовать их для своей команды и выполнять их.
Всё довольно просто, если не считать себя начальником. А через некоторое время – ещё и эффективно.