Ганник-специалист
Ганник - это лучший гладиатор Капуи, дома Лентула Батиата, живущий в 73 г. д.н. Есть хороший сериал про спартанцев, но суть не в этом.
Ганник великий мастер меча. Это гладиатор, получивший свободу, выиграв её на арене. В общем очень крутой специалист.
Была одна проблема. Ганнику было на все наплевать, его интересовали только женщины и вино. Когда его призывали помочь, он выполнял свою роль быстро и профессионально и уходил. Однажды его попросили возглавить часть армии восставших рабов. Он в агрессивной манере отказался и ушел.
В росте специалистов есть подобный момент.
Специалист, допустим сеньор, так быстро может решить какую-то задачу или найти решение, как Ганник - выйти и всем раздать люлей, но потом уйти в безразличие с мыслью "остальное доделают другие". А когда возникнет ситуация, что именно в такого специалиста верит вся команда, его просят возглавить проект, пасует или просит пачку менеджеров рангом пониже.
Важно, чтобы желание поработать руками и стать предводителем оставались. Без первого растеряется весь навык и можно отлететь от земли. Для второго, нужна смелость.
Не становитесь безразличными, притупите эго, если вы крутой спец. В ваших руках нуждаются, в вашем руководстве тоже. Вы можете вдохновить, вы можете решить, вы можете сделать круто.
5АМ | #команда
Ганник - это лучший гладиатор Капуи, дома Лентула Батиата, живущий в 73 г. д.н. Есть хороший сериал про спартанцев, но суть не в этом.
Ганник великий мастер меча. Это гладиатор, получивший свободу, выиграв её на арене. В общем очень крутой специалист.
Была одна проблема. Ганнику было на все наплевать, его интересовали только женщины и вино. Когда его призывали помочь, он выполнял свою роль быстро и профессионально и уходил. Однажды его попросили возглавить часть армии восставших рабов. Он в агрессивной манере отказался и ушел.
В росте специалистов есть подобный момент.
Специалист, допустим сеньор, так быстро может решить какую-то задачу или найти решение, как Ганник - выйти и всем раздать люлей, но потом уйти в безразличие с мыслью "остальное доделают другие". А когда возникнет ситуация, что именно в такого специалиста верит вся команда, его просят возглавить проект, пасует или просит пачку менеджеров рангом пониже.
Важно, чтобы желание поработать руками и стать предводителем оставались. Без первого растеряется весь навык и можно отлететь от земли. Для второго, нужна смелость.
Не становитесь безразличными, притупите эго, если вы крутой спец. В ваших руках нуждаются, в вашем руководстве тоже. Вы можете вдохновить, вы можете решить, вы можете сделать круто.
5АМ | #команда
Эмпатия к команде
Сейчас такой период, когда, по моим ощущениям, я впервые очень сильно отдалился от команды. Продажи, маркетинг, финансы, принятие решений - это моя зона ответственности, моя компетенция, мое направление. Честно, у меня такое ощущение, как будто я ухожу на охоту, а мое племя остается одно 😄. И, когда на долго уходишь, начинаешь скучать.
У меня есть один приём. Вся команда сейчас на удаленке. Я периодически вспоминаю о каждом и представляю как каждый из ребят сейчас сидит у компьютера: пишет код для фронта, бэка, что-нибудь дизайнит или пишет, ну или на перерыве пинает балду или играет в кибербанк😄
Так, я как будто подключаюсь к каждому, к проблемам и ощущениям каждого, чтобы прочувствовать контекст, в котором находится человек: будь то это Германия, Армения, Крым или Москва, опять же исходя из моих знаний о человеке.
Такое подключение может привести к мыслям о человеке, его проблемах, переживании и побудить связаться, узнать не просто "как там задача, бизнес-юнит", а "как ты там, человек, решивший идти вместе с нами". В этом разница.
Этот подход работает - когда не похер. Плохо - когда похер. Пусть будет меньше людей, которым похер.
5АМ | #команда
Сейчас такой период, когда, по моим ощущениям, я впервые очень сильно отдалился от команды. Продажи, маркетинг, финансы, принятие решений - это моя зона ответственности, моя компетенция, мое направление. Честно, у меня такое ощущение, как будто я ухожу на охоту, а мое племя остается одно 😄. И, когда на долго уходишь, начинаешь скучать.
У меня есть один приём. Вся команда сейчас на удаленке. Я периодически вспоминаю о каждом и представляю как каждый из ребят сейчас сидит у компьютера: пишет код для фронта, бэка, что-нибудь дизайнит или пишет, ну или на перерыве пинает балду или играет в кибербанк😄
Так, я как будто подключаюсь к каждому, к проблемам и ощущениям каждого, чтобы прочувствовать контекст, в котором находится человек: будь то это Германия, Армения, Крым или Москва, опять же исходя из моих знаний о человеке.
Такое подключение может привести к мыслям о человеке, его проблемах, переживании и побудить связаться, узнать не просто "как там задача, бизнес-юнит", а "как ты там, человек, решивший идти вместе с нами". В этом разница.
Этот подход работает - когда не похер. Плохо - когда похер. Пусть будет меньше людей, которым похер.
5АМ | #команда
Настя - наш новый тестировщик, просто пришла и сделала красиво. Просто без херни, без "многослов", когда профи уже знает как надо и как должно быть.
Женя, наш мега фронт, как-то сформулировал лучшего тестировщика так: "Я должен его ненавидеть".
Настю он хотел бы ненавидеть, но любовь превалирует. Работы у наших фронтов сильно прибавилось))
5АМ | #команда
Женя, наш мега фронт, как-то сформулировал лучшего тестировщика так: "Я должен его ненавидеть".
Настю он хотел бы ненавидеть, но любовь превалирует. Работы у наших фронтов сильно прибавилось))
5АМ | #команда
"Так что делаем то, начальник?"
Помню как-то в 2017-м году я садился писать код для пет проекта. Похрустывая пальцами, задавался вопросом, а собственно что писать то. Тогда еще пришла мысль, что навыки програмиста, продакта/проджекта, художника имеют одно и то же свойство. Они отвечают на вопрос КАК сделать, но не ЧТО.
"Что делаем" - гораздо более сложный вопрос. За что заплатят? Что нужно? Его невозможно делегировать на 100%. Когда отвечаешь на вопрос "что делаем" автоматом принимаешь позицию лидера, потому что выбираешь какой дорогой идти, а значит берешь ответственность.
Вот именно "что" является тем маркером, до которого нужно делегировать. Все остальное могут сделать лучше отдельные специалисты, когда они знают что нужно делать. "Что делать будем" - это постоянное решение проблем.
5АМ | #команда
Помню как-то в 2017-м году я садился писать код для пет проекта. Похрустывая пальцами, задавался вопросом, а собственно что писать то. Тогда еще пришла мысль, что навыки програмиста, продакта/проджекта, художника имеют одно и то же свойство. Они отвечают на вопрос КАК сделать, но не ЧТО.
"Что делаем" - гораздо более сложный вопрос. За что заплатят? Что нужно? Его невозможно делегировать на 100%. Когда отвечаешь на вопрос "что делаем" автоматом принимаешь позицию лидера, потому что выбираешь какой дорогой идти, а значит берешь ответственность.
Вот именно "что" является тем маркером, до которого нужно делегировать. Все остальное могут сделать лучше отдельные специалисты, когда они знают что нужно делать. "Что делать будем" - это постоянное решение проблем.
5АМ | #команда
Как провожу собеседования с кандидатами в команду (ч. 1/3)
Вчера проводил собеседование и в очередной раз заметил, что повторяю одни и те же смыслы. Они помогли нам собраться вместе и делать крутое. Решил написать о них, чтобы потом можно было пересылать, ну и вам возможно будет интересно.
Базово процесс выглядит как у всех: Никита ищет и связывается, потом выводит на собес с ребятами, потом на меня, потом делаем оффер.
5АМ | #команда
Вчера проводил собеседование и в очередной раз заметил, что повторяю одни и те же смыслы. Они помогли нам собраться вместе и делать крутое. Решил написать о них, чтобы потом можно было пересылать, ну и вам возможно будет интересно.
Базово процесс выглядит как у всех: Никита ищет и связывается, потом выводит на собес с ребятами, потом на меня, потом делаем оффер.
5АМ | #команда
Как провожу собеседования с кандидатами в команду (ч. 2/3)
1️⃣Смысл №1: Весь опыт человека решает
В IT часто переходят ребята из других областей. Я видел: политиков, социологов, инженеров, финансистов, экономистов, продажников, ресничников, астрологов, маммологов и кого только не.
Поэтому мы с Никитой решили внедрять логику воспроизведения таймлайна жизни человека. Прям по годам восстанавливаются ключевые точки жизни человека: вот в 2017-м ты продавал зубную пасту, в 2018-м вел проект по отделке помещений, а в 2019-м херак, и ты тестировщик. Я придерживаюсь логики "отталкивайся от имеющегося", поэтому важно понимать как прошлый жизненный и рабочий опыт человека влияет на его текущую профессию.
Допустим дизайнер, пришедший с архитектуры, будет лучше сечь в UI, исходя из своего понимания композиции и гармонии, т.к. на первом курсе приходилось рисовать обнаженные писки греко-римских политиков. А вот продажник или мент, будет лучше сечь в глобальном UX, т.к. лучше понимает за бизнес и деньги.
Коротко: Даже нерелевантный опыт влияет на результат.
2️⃣Смысл №2: Нам интересно, что человек реально делал, а не какие умные книжные методики знает
Вопрос: а что ты делал каждый день, когда приходил на работу или садился за компьютер в этой фирме в таком-то году. Человек может уводить вправо-влево, но нужно возвращать.
Этот вопрос ставит все на свои места. Ты понимаешь из чего реально состоит опыт человека. Я рисовал UI-kit и помогал делать компоненты, которые меня просил делать мой диз руководитель. Ок, то есть ты не мидл UX/UI дизайнер, так как если бы им был, то сказал бы, что я получил доку от аналитика утром, посовещался бы с ним с утреца, помимо обсуждая мемасы, созвонился бы с парой пользователей после обеда, поспрашивал как надо, накидал бы блок-схему и сценарии вечерком, с неё вайерфреймы, а потом уже задизайнил бы по кейсам требования аналитика.
И это не тоже самое, что умею строить CJM, проводить глубинное интервью, разрабатывать макеты. После такого я не знаю, что реально человек умеет, а во втором у меня формируется образ, что человек работает в команде, знает бизнес процесс производства, понимаю направленность этого опыта: корпоративный или стартаповский.
Коротко: Только реальные действия образуют опыт человека. Преобразовать теорию человека в опыт - инвестиции компании.
3️⃣Смысл №3: Адекватность
Сложный смысл. Так как адекватность строится на понимании ограниченности ресурсов. Есть веер методик, тысяча способов сделать что-то, десятки вариантов развития событий. Каждый специалист в IT: продакт, дизайнер, разработчик, тестер и другие, должны помнить о том, что смысл их работы в создании ценности, которая будет продана тем, кто за это захочет заплатить. Эти деньги, которыми эти люди расплатятся, будут теми, которыми будут выплачиваться зарплаты. IT - это 90% кадры.
Так вот, если человек приходит в компанию, он должен адекватно воспринимать на чем компания зарабатывает, откуда деньги, Зин, и каким образом мы их тратим. Таким образом человек будет понимать, что строить CJM-ку 2 месяца, чтобы на нее посмотрело 2 человека, пожали плечами и пошли дальше, не стоит того, чтобы отдать за нее 300 тысяч (при средней ЗП в 150к). Нужно найти другие решения граничащие между "ну писец, если это не сделать - будет хаос" и "еба, фронты получат задачу через 3 месяца только".
Коротко: Думать своей головой, исходить из контекста, а не делать, потому что так делают всеВТБ или АльфаБанк.
4️⃣Смысл №4: Взаимопомощь
Или ассистирование. Человек должен либо уже понимать либо хотеть понять цепочку производства IT продукта. Так, он будет знать, от кого он получает материалы и данные и для кого создает свои.
У нас в команде выстроено так, что каждый думает о том, кто "спереди" и о том, кто "сзади" в цепочке создания ценности. Условно, дизайнер думает и об аналитике, помогает ему в обнаружении требований или подсвечивает, что требования херня, и также думает и о фронтах, которые будут читать его дизайн.
Коротко: Не быть одиночкой, а думать о других.
5АМ | #команда
1️⃣Смысл №1: Весь опыт человека решает
В IT часто переходят ребята из других областей. Я видел: политиков, социологов, инженеров, финансистов, экономистов, продажников, ресничников, астрологов, маммологов и кого только не.
Поэтому мы с Никитой решили внедрять логику воспроизведения таймлайна жизни человека. Прям по годам восстанавливаются ключевые точки жизни человека: вот в 2017-м ты продавал зубную пасту, в 2018-м вел проект по отделке помещений, а в 2019-м херак, и ты тестировщик. Я придерживаюсь логики "отталкивайся от имеющегося", поэтому важно понимать как прошлый жизненный и рабочий опыт человека влияет на его текущую профессию.
Допустим дизайнер, пришедший с архитектуры, будет лучше сечь в UI, исходя из своего понимания композиции и гармонии, т.к. на первом курсе приходилось рисовать обнаженные писки греко-римских политиков. А вот продажник или мент, будет лучше сечь в глобальном UX, т.к. лучше понимает за бизнес и деньги.
Коротко: Даже нерелевантный опыт влияет на результат.
2️⃣Смысл №2: Нам интересно, что человек реально делал, а не какие умные книжные методики знает
Вопрос: а что ты делал каждый день, когда приходил на работу или садился за компьютер в этой фирме в таком-то году. Человек может уводить вправо-влево, но нужно возвращать.
Этот вопрос ставит все на свои места. Ты понимаешь из чего реально состоит опыт человека. Я рисовал UI-kit и помогал делать компоненты, которые меня просил делать мой диз руководитель. Ок, то есть ты не мидл UX/UI дизайнер, так как если бы им был, то сказал бы, что я получил доку от аналитика утром, посовещался бы с ним с утреца, помимо обсуждая мемасы, созвонился бы с парой пользователей после обеда, поспрашивал как надо, накидал бы блок-схему и сценарии вечерком, с неё вайерфреймы, а потом уже задизайнил бы по кейсам требования аналитика.
И это не тоже самое, что умею строить CJM, проводить глубинное интервью, разрабатывать макеты. После такого я не знаю, что реально человек умеет, а во втором у меня формируется образ, что человек работает в команде, знает бизнес процесс производства, понимаю направленность этого опыта: корпоративный или стартаповский.
Коротко: Только реальные действия образуют опыт человека. Преобразовать теорию человека в опыт - инвестиции компании.
3️⃣Смысл №3: Адекватность
Сложный смысл. Так как адекватность строится на понимании ограниченности ресурсов. Есть веер методик, тысяча способов сделать что-то, десятки вариантов развития событий. Каждый специалист в IT: продакт, дизайнер, разработчик, тестер и другие, должны помнить о том, что смысл их работы в создании ценности, которая будет продана тем, кто за это захочет заплатить. Эти деньги, которыми эти люди расплатятся, будут теми, которыми будут выплачиваться зарплаты. IT - это 90% кадры.
Так вот, если человек приходит в компанию, он должен адекватно воспринимать на чем компания зарабатывает, откуда деньги, Зин, и каким образом мы их тратим. Таким образом человек будет понимать, что строить CJM-ку 2 месяца, чтобы на нее посмотрело 2 человека, пожали плечами и пошли дальше, не стоит того, чтобы отдать за нее 300 тысяч (при средней ЗП в 150к). Нужно найти другие решения граничащие между "ну писец, если это не сделать - будет хаос" и "еба, фронты получат задачу через 3 месяца только".
Коротко: Думать своей головой, исходить из контекста, а не делать, потому что так делают все
4️⃣Смысл №4: Взаимопомощь
Или ассистирование. Человек должен либо уже понимать либо хотеть понять цепочку производства IT продукта. Так, он будет знать, от кого он получает материалы и данные и для кого создает свои.
У нас в команде выстроено так, что каждый думает о том, кто "спереди" и о том, кто "сзади" в цепочке создания ценности. Условно, дизайнер думает и об аналитике, помогает ему в обнаружении требований или подсвечивает, что требования херня, и также думает и о фронтах, которые будут читать его дизайн.
Коротко: Не быть одиночкой, а думать о других.
5АМ | #команда
Как провожу собеседования с кандидатами в команду (ч. 3/3)
5️⃣Смысл №5: Социальное управление
Есть такой термин, или я сам его выдумал, не знаю. Руководитель очень сильно влияет на сотрудника. Он может как убить в человеке все желание, сделать из него глухого эгоистичного баблодела, а может вырастить его как тренер крутого спортсмена. Для этого нужно понимать особенности человека, сильные и слабые стороны, его опыт (маммолога) и выстроить карту развития.
Так закрываются две задачи: во-первых, человек растет и приносит профит команде, что самое важное, а, во-вторых, другие компании потом получат тоже хорошего специалиста, если человек уйдет из команды. Эдакая забота о стране) Чушь конечно, но я несу такие ценности.
Коротко: Вкладываемся в людей и заинтересованы в развитии
6️⃣Смысл №6: Каждый - рок-звезда
Документация - это хорошо. Хорошо, когда человек делает так, как сказали - по заданию, но истинно крутые продукты создаются, когда каждый в своей точке добавляет свое видение. А добавлять свое видение - это как цветение. Если попытаться руками раскрыть цветок - он не раскроется. Так и с членом команды - должен нравится продукт, должна нравится команда, должно быть внутри не похер, должно быть все хорошо по денежкам, тогда будет цветение.
Коротко: Видение закладывают все, поэтому новый человек в команде - это новое видение.
Что думаете по этим смыслам-ценностям? Считаете их важными для себя? Пишите нам тогда))
5АМ | #команда
5️⃣Смысл №5: Социальное управление
Есть такой термин, или я сам его выдумал, не знаю. Руководитель очень сильно влияет на сотрудника. Он может как убить в человеке все желание, сделать из него глухого эгоистичного баблодела, а может вырастить его как тренер крутого спортсмена. Для этого нужно понимать особенности человека, сильные и слабые стороны, его опыт (маммолога) и выстроить карту развития.
Так закрываются две задачи: во-первых, человек растет и приносит профит команде, что самое важное, а, во-вторых, другие компании потом получат тоже хорошего специалиста, если человек уйдет из команды. Эдакая забота о стране) Чушь конечно, но я несу такие ценности.
Коротко: Вкладываемся в людей и заинтересованы в развитии
6️⃣Смысл №6: Каждый - рок-звезда
Документация - это хорошо. Хорошо, когда человек делает так, как сказали - по заданию, но истинно крутые продукты создаются, когда каждый в своей точке добавляет свое видение. А добавлять свое видение - это как цветение. Если попытаться руками раскрыть цветок - он не раскроется. Так и с членом команды - должен нравится продукт, должна нравится команда, должно быть внутри не похер, должно быть все хорошо по денежкам, тогда будет цветение.
Коротко: Видение закладывают все, поэтому новый человек в команде - это новое видение.
Что думаете по этим смыслам-ценностям? Считаете их важными для себя? Пишите нам тогда))
5АМ | #команда
Решаю вопрос расширения команды.
Вот прикиньте, что вы таки выстрадали огромный it продукт - веб ЛК, мобильное приложение и инженерное решение. Первый прототип сделала команда внештатных специалистов, второй прототип - команда, принявшая стек внештатных спецов, третья - пересобрала и выпустила первую версию, которая теперь продается.
Мне нужно продавать продукт первой версии, поддерживать его, но готовить релиз второй версии, который можно продавать массово. Это реальность работы в условиях ограниченных издержек. Итак нужна стратегия как из состояния №1 трансформироваться в состояние №2.
Состояние №1: Команда перегруженная поддержкой старых проектов, первой версии и разработкой второй. Команды продаж, внедрения и маркетинга нет. 10 человек в команде
Состояние №2: Параллельно работающие команды разработки над всей сеткой продуктов в связке с отделом продаж. 20-30 человек в команде.
Стратегия. Я использую подход плавных микротрансформаций и закрывающих хвостов с распределением обязанностей.
Создание текущей команды считаю огромным успехом и достижением, т.к. все в команде теперь носители продуктового видения, а не только я - это результат 3-х лет работы. Эта эмерджентность стоит очень дорого.
Но как сделать так, чтобы удвоить существующую команду разработки и тем более добавить к ней еще и команду продаж. Это для меня новый опыт и новый вызов.
Пока решил:
- текущая команда держится на клее в виде меня, а теперь моего клея будет недостаточно. Каждый должен стать клеем для новых ребят, я даю место ребятам творить, потому что они лучше знают как;
- нужно упорядочить комплекс приложений, держащих бизнес и разработку, должен быть подготовлен к удвоению, а то и утроению команды, а значит повышенные требования к онбордингу, безопасности, процессности;
- изменить подход к финансовому планированию, управлению проектами, процессам найма должен быть другим; нужно запастись терпения, т.к. новые люди будут очень медленно понимать продукт и процессы, а терпение - это заложенный бюджет на низкую эффективность и обучение продукту.
Как бы решал ты? Что еще бы учел?
5АМ | #команда
Вот прикиньте, что вы таки выстрадали огромный it продукт - веб ЛК, мобильное приложение и инженерное решение. Первый прототип сделала команда внештатных специалистов, второй прототип - команда, принявшая стек внештатных спецов, третья - пересобрала и выпустила первую версию, которая теперь продается.
Мне нужно продавать продукт первой версии, поддерживать его, но готовить релиз второй версии, который можно продавать массово. Это реальность работы в условиях ограниченных издержек. Итак нужна стратегия как из состояния №1 трансформироваться в состояние №2.
Состояние №1: Команда перегруженная поддержкой старых проектов, первой версии и разработкой второй. Команды продаж, внедрения и маркетинга нет. 10 человек в команде
Состояние №2: Параллельно работающие команды разработки над всей сеткой продуктов в связке с отделом продаж. 20-30 человек в команде.
Стратегия. Я использую подход плавных микротрансформаций и закрывающих хвостов с распределением обязанностей.
Создание текущей команды считаю огромным успехом и достижением, т.к. все в команде теперь носители продуктового видения, а не только я - это результат 3-х лет работы. Эта эмерджентность стоит очень дорого.
Но как сделать так, чтобы удвоить существующую команду разработки и тем более добавить к ней еще и команду продаж. Это для меня новый опыт и новый вызов.
Пока решил:
- текущая команда держится на клее в виде меня, а теперь моего клея будет недостаточно. Каждый должен стать клеем для новых ребят, я даю место ребятам творить, потому что они лучше знают как;
- нужно упорядочить комплекс приложений, держащих бизнес и разработку, должен быть подготовлен к удвоению, а то и утроению команды, а значит повышенные требования к онбордингу, безопасности, процессности;
- изменить подход к финансовому планированию, управлению проектами, процессам найма должен быть другим; нужно запастись терпения, т.к. новые люди будут очень медленно понимать продукт и процессы, а терпение - это заложенный бюджет на низкую эффективность и обучение продукту.
Как бы решал ты? Что еще бы учел?
5АМ | #команда
Решил проблему с блоком разработки АПИ для нового сайта
Интересный пример из жизни одного принципа, который я вывел в прошлогоднем посте. Называется расщепить-распараллелить. Думаю, что бóльшая часть проблем и гениальных решений к этим проблемам лежит в плоскости правильного разделения сцепленных вещей.
Задача такая: сделать запросы для передачи данных из одной БД в другую для их отображения на сайте. Делаем ТЗ и понимаем, что там нужно взять старые переменные, создать новые переменные и подготовить их к переносу. Разработчик, который создает API говорит, что делать 2-3 недели. "Звиздец" - подумал я, так как еще и затянул с передачей ТЗ, плюс еще и фронт разработчики стоят, потому что им нужны запросы.
Начал искать решение.
Дал задание hr-у Никите найти разрабов на стороне. Вдруг сделают быстрее. Сделали бы быстрее, но пришлось бы потратить столько же времени для погружения в контекст. Да и поддерживать текущий разраб смог бы в будущем лучше.
Пошел думать дальше - "что-то же будет готово у него за первую неделю" - подумал я. "А что?" Еще раз вспомнил ТЗ, а там фактически такие задачи:
1) Создать недостающие переменные и привести в порядок старые.
2) Перенести данные из старых переменных в новые, т.е. сделать миграцию.
3) Сделать сами запросы.
А что нужно фронтам:
1) Сверстать и подключить элементы списка с этими данными и логикой. Подготовить модель для отображения.
2) Прицепить запросы из БД, в которую попадают данные из обмена.
Так, получилось, что оба разрабов нуждаются друг в друге только в своих первых пунктах. Решили, что разраб по АПИ должен сделать таблицу и заполнить тестовыми данными, чтобы разраб фронта мог проверить отображение и сделать пользовательскую логику пока первый будет дорабатывать сами запросы.
В итоге с 3 недель срок блока снялся до 1 недели, просто нужно было убрать строгий подход к разработке один за одним и разделить.
Отделять мух от котлет по мне так самый важный навык руководителя, поэтому нужно быть дотошным до деталей: точки расщепления могут быть в самых неожиданных вещах.
5AM | #команда
Интересный пример из жизни одного принципа, который я вывел в прошлогоднем посте. Называется расщепить-распараллелить. Думаю, что бóльшая часть проблем и гениальных решений к этим проблемам лежит в плоскости правильного разделения сцепленных вещей.
Задача такая: сделать запросы для передачи данных из одной БД в другую для их отображения на сайте. Делаем ТЗ и понимаем, что там нужно взять старые переменные, создать новые переменные и подготовить их к переносу. Разработчик, который создает API говорит, что делать 2-3 недели. "Звиздец" - подумал я, так как еще и затянул с передачей ТЗ, плюс еще и фронт разработчики стоят, потому что им нужны запросы.
Начал искать решение.
Дал задание hr-у Никите найти разрабов на стороне. Вдруг сделают быстрее. Сделали бы быстрее, но пришлось бы потратить столько же времени для погружения в контекст. Да и поддерживать текущий разраб смог бы в будущем лучше.
Пошел думать дальше - "что-то же будет готово у него за первую неделю" - подумал я. "А что?" Еще раз вспомнил ТЗ, а там фактически такие задачи:
1) Создать недостающие переменные и привести в порядок старые.
2) Перенести данные из старых переменных в новые, т.е. сделать миграцию.
3) Сделать сами запросы.
А что нужно фронтам:
1) Сверстать и подключить элементы списка с этими данными и логикой. Подготовить модель для отображения.
2) Прицепить запросы из БД, в которую попадают данные из обмена.
Так, получилось, что оба разрабов нуждаются друг в друге только в своих первых пунктах. Решили, что разраб по АПИ должен сделать таблицу и заполнить тестовыми данными, чтобы разраб фронта мог проверить отображение и сделать пользовательскую логику пока первый будет дорабатывать сами запросы.
В итоге с 3 недель срок блока снялся до 1 недели, просто нужно было убрать строгий подход к разработке один за одним и разделить.
Отделять мух от котлет по мне так самый важный навык руководителя, поэтому нужно быть дотошным до деталей: точки расщепления могут быть в самых неожиданных вещах.
5AM | #команда
Как не нервничать при управлении командой?
Недавно со мной произошел интересный случай.
Нам нужно было выпустить два релиза мобильного приложения: один — срочно для одного клиента, а второй — для другого. Понимаю, что первый релиз нужен "вчера", а второй можно немного отложить. Я расставил приоритеты: первый релиз важнее, и сообщил об этом в текстах, чате и голосом на планерках. Повторил несколько раз.
Проходят выходные. Смотрю в понедельник: делаются задачи по второму релизу. Думаю, ладно, может, что-то возникло, не буду вмешиваться. На следующий день снова работаем по второму релизу, первый стоит, а его релиз уже завтра. Начинаю выяснять: оказывается, по первому релизу задачи выполнены, но его хотят выпустить одновременно со вторым. В среднем релиз в мобильные сторы занимает 2–3 дня.
Понимаю, что мы опаздываем. Внутри закипает. Демон в голове твердит: “Блин, я же сказал, сначала первый!”. Останавливаюсь и задаю себе вопрос: “Что я сделал как собственник, чтобы приоритет был четко поставлен на контроль?” (Это еще при том, что я пропустил планерку в понедельник утром.) Ответ: я обозначил приоритет, но как? В чате и голосом. И успокоился. Почему?
Давайте посчитаем. Два релиза, две разные задачи. Нужно завести задачу, расставить теги, сделать детальное описание, провести декомпозицию, созвониться, вечером еще раз уточнить: “А как, а что?”.
То есть, как собственник, я должен создать и оплатить процесс контроля приоритетов. Я оплачиваю время разработчика, а не время на контроль приоритетов и задач. Это значит, что я экономлю на микроменеджменте минимум 1.5 ляма в год. Но какие риски при этом беру на себя?
В целом, команда маленькая, задачи контролировать не так сложно, особенно когда все мотивированы, но иногда возникают рискованные моменты. Вот и мои риски экономии.
Я за них заплатил сроком выхода, из которого я могу извернуться как уж, но сколько я сэкономил? Ответ приходит сразу: ты перестаешь нервничать и принимаешь ситуацию.
А что произошло-то? Один из ребят просто приболел на выходных, осень же, и немного забыл о приоритетах. Это может случиться с каждым.
Нервы — это всегда когда мы кому-то что-то должны, но не можем уложиться в срок.
Херня случается, риски бывают — надо менять планы и договариваться заново.
5АМ | #команда
Недавно со мной произошел интересный случай.
Нам нужно было выпустить два релиза мобильного приложения: один — срочно для одного клиента, а второй — для другого. Понимаю, что первый релиз нужен "вчера", а второй можно немного отложить. Я расставил приоритеты: первый релиз важнее, и сообщил об этом в текстах, чате и голосом на планерках. Повторил несколько раз.
Проходят выходные. Смотрю в понедельник: делаются задачи по второму релизу. Думаю, ладно, может, что-то возникло, не буду вмешиваться. На следующий день снова работаем по второму релизу, первый стоит, а его релиз уже завтра. Начинаю выяснять: оказывается, по первому релизу задачи выполнены, но его хотят выпустить одновременно со вторым. В среднем релиз в мобильные сторы занимает 2–3 дня.
Понимаю, что мы опаздываем. Внутри закипает. Демон в голове твердит: “Блин, я же сказал, сначала первый!”. Останавливаюсь и задаю себе вопрос: “Что я сделал как собственник, чтобы приоритет был четко поставлен на контроль?” (Это еще при том, что я пропустил планерку в понедельник утром.) Ответ: я обозначил приоритет, но как? В чате и голосом. И успокоился. Почему?
Давайте посчитаем. Два релиза, две разные задачи. Нужно завести задачу, расставить теги, сделать детальное описание, провести декомпозицию, созвониться, вечером еще раз уточнить: “А как, а что?”.
То есть, как собственник, я должен создать и оплатить процесс контроля приоритетов. Я оплачиваю время разработчика, а не время на контроль приоритетов и задач. Это значит, что я экономлю на микроменеджменте минимум 1.5 ляма в год. Но какие риски при этом беру на себя?
В целом, команда маленькая, задачи контролировать не так сложно, особенно когда все мотивированы, но иногда возникают рискованные моменты. Вот и мои риски экономии.
Я за них заплатил сроком выхода, из которого я могу извернуться как уж, но сколько я сэкономил? Ответ приходит сразу: ты перестаешь нервничать и принимаешь ситуацию.
А что произошло-то? Один из ребят просто приболел на выходных, осень же, и немного забыл о приоритетах. Это может случиться с каждым.
Нервы — это всегда когда мы кому-то что-то должны, но не можем уложиться в срок.
Херня случается, риски бывают — надо менять планы и договариваться заново.
5АМ | #команда