Про стандартизацию
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть production-ready проект с кучей интеграций, проверок и понятным release-флоу, а своё время тратить на решение проблем бизнеса. Все в команде знают, как писать js или ruby, всем понятно что писать в пулл-реквестах, все могут просто копипастить конфиг для CI, который уже претерпел пару десятков итераций и решает сотни проблем. А деплой будет работать как для одного сервера, так и для кластера из 10 – и думать об этом на старте не нужно.
О чем нужно помнить, стандартизируя процессы?
– Система ≠ бюрократия. «Где задачку брали – туда и за апрувом идите. И вообще не видите, у нас обед?»
– Система должна ускорять и упрощать, а не наоборот
– Отвечайте на вопрос почему. «Окей, мы используем 2 пробела, а не 4. А где я могу почитать внутренний срачик на эту тему и его итоги?»
– Нужна возможность для обхода системы. «Проверка на гитхабе загорелась красным, но мне некогда править опечатки – на проде пожар! Как мне зарелизиться?»
– Нужен прозрачный формат улучшения. «Ребята, есть идея для обсуждения – а может уже попробуем react вместо jquery?»
– Нужно место и время для экспериментов. Время для анархии, чтобы люди понимали пользу стандартов (например, хакатоны). Небольшие проекты, чтобы пробовать что-то новое и улучшать стандарты.
– Нужно ставить стандарты под сомнение. Каждый раз, применяя тот или иной стандарт нужно задумываться, а не стал ли он карго-культом?
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть production-ready проект с кучей интеграций, проверок и понятным release-флоу, а своё время тратить на решение проблем бизнеса. Все в команде знают, как писать js или ruby, всем понятно что писать в пулл-реквестах, все могут просто копипастить конфиг для CI, который уже претерпел пару десятков итераций и решает сотни проблем. А деплой будет работать как для одного сервера, так и для кластера из 10 – и думать об этом на старте не нужно.
О чем нужно помнить, стандартизируя процессы?
– Система ≠ бюрократия. «Где задачку брали – туда и за апрувом идите. И вообще не видите, у нас обед?»
– Система должна ускорять и упрощать, а не наоборот
– Отвечайте на вопрос почему. «Окей, мы используем 2 пробела, а не 4. А где я могу почитать внутренний срачик на эту тему и его итоги?»
– Нужна возможность для обхода системы. «Проверка на гитхабе загорелась красным, но мне некогда править опечатки – на проде пожар! Как мне зарелизиться?»
– Нужен прозрачный формат улучшения. «Ребята, есть идея для обсуждения – а может уже попробуем react вместо jquery?»
– Нужно место и время для экспериментов. Время для анархии, чтобы люди понимали пользу стандартов (например, хакатоны). Небольшие проекты, чтобы пробовать что-то новое и улучшать стандарты.
– Нужно ставить стандарты под сомнение. Каждый раз, применяя тот или иной стандарт нужно задумываться, а не стал ли он карго-культом?
Слова паразиты, часть 1
— А нельзя было нормально протестировать?
— Я это не сделал, потому что менеджер нормально задачу не оформил!
— Когда ты станешь нормальным разработчиком – тогда зарплату и повысим
— Ты не нормально с клиентом разговариваешь!
— А может мы будем нормальные процессы использовать?
Слово нормально в последнее время стало для меня триггером – если человек его употребляет, значит он не может давать конструктивный фидбек. Плохо, нормально, хорошо – эти слова помогают выразить ваше отношение к чему-либо, но дают 0 информации собеседнику о том, что вы имеете ввиду. Хотите чтобы люди нормально делали – давайте нормальный фидбек. Рассказывайте, что для вас норма
— А нельзя было нормально протестировать?
— Я это не сделал, потому что менеджер нормально задачу не оформил!
— Когда ты станешь нормальным разработчиком – тогда зарплату и повысим
— Ты не нормально с клиентом разговариваешь!
— А может мы будем нормальные процессы использовать?
Слово нормально в последнее время стало для меня триггером – если человек его употребляет, значит он не может давать конструктивный фидбек. Плохо, нормально, хорошо – эти слова помогают выразить ваше отношение к чему-либо, но дают 0 информации собеседнику о том, что вы имеете ввиду. Хотите чтобы люди нормально делали – давайте нормальный фидбек. Рассказывайте, что для вас норма
Про Николая Иронова
Тяжелый физический труд, рутинные задачи, конвеерное производство. Задачи офисных сотрудников, телефония. Так постепенно автоматизация проникала в разные сферы бизнеса. Сейчас всё чаще пытаются автоматизировать и заменить разработчиков. Но всегда считалось, что дизайн – это исскуство и робот никогда не заменит дизайнера.
Но ведь всегда лучше попборовать, а не гадать. Причём можно сделать это не в виде эксперимента, а сразу с внедрением в бизнес и получать по 100к рублей за каждую работу нейросети, заменяющей дизайнера. Не хочу вдаваться в оценку работ, но сам факт такого внедрения – это ещё один шаг в сторону выполнения работы людей программами, хотя бы для достижения быстрых, но не идеальных результатов. Ещё немного и нейросети преодолеют склон просвещения и выйдут на плато продуктивности – тогда большинство компаний будут применять нейросети в своих повседневных задачах.
Если не хотите потерять в ценности из-за развития технологий – задумайтесь, а не занимаетесь ли вы одним и тем же изо дня в день? Если вы примете участие в роли консультанта в разработке нейросети, которая будет выполнять бóльшую часть ваших рутинных задач – останется ли что-то для вас? Сможете ли вы развивать её или она заменит вас полностью?
И что думаете о работах Иронова?
👨🎨 – настоящее искусство
🤖 - нет в них души
Тяжелый физический труд, рутинные задачи, конвеерное производство. Задачи офисных сотрудников, телефония. Так постепенно автоматизация проникала в разные сферы бизнеса. Сейчас всё чаще пытаются автоматизировать и заменить разработчиков. Но всегда считалось, что дизайн – это исскуство и робот никогда не заменит дизайнера.
Но ведь всегда лучше попборовать, а не гадать. Причём можно сделать это не в виде эксперимента, а сразу с внедрением в бизнес и получать по 100к рублей за каждую работу нейросети, заменяющей дизайнера. Не хочу вдаваться в оценку работ, но сам факт такого внедрения – это ещё один шаг в сторону выполнения работы людей программами, хотя бы для достижения быстрых, но не идеальных результатов. Ещё немного и нейросети преодолеют склон просвещения и выйдут на плато продуктивности – тогда большинство компаний будут применять нейросети в своих повседневных задачах.
Если не хотите потерять в ценности из-за развития технологий – задумайтесь, а не занимаетесь ли вы одним и тем же изо дня в день? Если вы примете участие в роли консультанта в разработке нейросети, которая будет выполнять бóльшую часть ваших рутинных задач – останется ли что-то для вас? Сможете ли вы развивать её или она заменит вас полностью?
И что думаете о работах Иронова?
👨🎨 – настоящее искусство
🤖 - нет в них души
Главный вопрос
Есть люди, которые избегают вопроса «почему». Если руководитель спросит такого человека, почему он сделал именно так – он будет думать, что руководитель «включает начальника», «давит авторитетом», хочет «завалить» решение. Если спросит просто коллега – будет думать, что тот недостаточно умён, чтобы понять самому. Если подчинённый – «он что, сомневается в моих решениях!?». Обычно, те же люди не задают вопросы сами.
А ответы на этот вопрос – это «клей» для команд. Когда члены команды понимают историю принятия решения и его причины – они не будут ставить его под сомнение. Когда люди имеют возможность открыто задавать вопросы, не боясь показаться глупым, они вскрывают все недоработки менеджмента, вспоминают о забытых идеях, понимают выбранные приоритеты и выбирают оптимальные пути решения. Зная, что нужно публично ответить на вопрос «почему мы делаем именно это?» менеджеры составляют более осознанный план и занимаются более глубокой рефлексией своих действий. У любой задачи может быть много правильных решений, поэтому и для разработчиков/дизайнеров важно понимать, почему коллега выбрал именно этот путь – так проще в будущем поддерживать этот код и принимать подобные решения.
Культура открытых вопросов – драйвер роста ваших команд. Как начать выстраивать такую культуру?
— Сразу отвечай в своей работе «почему так?», не дожидаясь явного вопроса
— Не воспринимай вопросы, как индикатор критики или глупости
— Потрать время на объяснение – инвестиция этого времени быстро начнёт себя окупать
— Не стесняйся задавать вопросы
— Не бойся задавать неудобные вопросы
— Не скрывай правду. Даже если планируешь что-то сделать просто потому, что кажется что это сработает или просто интересно/хочется это сделать – так всем и говори!
Есть люди, которые избегают вопроса «почему». Если руководитель спросит такого человека, почему он сделал именно так – он будет думать, что руководитель «включает начальника», «давит авторитетом», хочет «завалить» решение. Если спросит просто коллега – будет думать, что тот недостаточно умён, чтобы понять самому. Если подчинённый – «он что, сомневается в моих решениях!?». Обычно, те же люди не задают вопросы сами.
А ответы на этот вопрос – это «клей» для команд. Когда члены команды понимают историю принятия решения и его причины – они не будут ставить его под сомнение. Когда люди имеют возможность открыто задавать вопросы, не боясь показаться глупым, они вскрывают все недоработки менеджмента, вспоминают о забытых идеях, понимают выбранные приоритеты и выбирают оптимальные пути решения. Зная, что нужно публично ответить на вопрос «почему мы делаем именно это?» менеджеры составляют более осознанный план и занимаются более глубокой рефлексией своих действий. У любой задачи может быть много правильных решений, поэтому и для разработчиков/дизайнеров важно понимать, почему коллега выбрал именно этот путь – так проще в будущем поддерживать этот код и принимать подобные решения.
Культура открытых вопросов – драйвер роста ваших команд. Как начать выстраивать такую культуру?
— Сразу отвечай в своей работе «почему так?», не дожидаясь явного вопроса
— Не воспринимай вопросы, как индикатор критики или глупости
— Потрать время на объяснение – инвестиция этого времени быстро начнёт себя окупать
— Не стесняйся задавать вопросы
— Не бойся задавать неудобные вопросы
— Не скрывай правду. Даже если планируешь что-то сделать просто потому, что кажется что это сработает или просто интересно/хочется это сделать – так всем и говори!
Создавай систему
Что полезнее, один раз сходить на пробежку в 15км и упасть от бессилия или регулярно 2 раза в неделю бегать по 3км? Прочитать «Войну и мир» или постоянно читать и заниматься самообразованием? Кто больше ценится в команде – тот, кто может «затащить» перед дедлайном, работая без передышек и задерживаясь на работе или тот, кто стабильно выдает крутой результат, заканчивая работать в 18:00?
Очевидно, что в долгосрочной перспективе, как для отдельно взятого человека, так и для команды побеждает система – меньше стресса, больше результатов, качество которых постоянно растёт. Да, ты можешь находиться на «пике» за счёт единоразовых сверхусилий или удачи, но через какое-то время ты оттуда слетишь, если не будет системы. Какой процент исполнителей, популярных позапрошлым летом ты помнишь сейчас? А какие гениальные стартапы, которые быстро взелетели 5 лет назад ещё существуют?
Система – это ускорение. Если ты двигаешься медленно, но с постоянным ускорением, через какое-то время ты обгонишь тех, кто уже сейчас двигается быстро, но с постоянной скоростью. Хочешь постоянно «лезть» вверх, ускоряясь?
Работая над системой, вместо постоянного решения возникающих проблем, можно избежать ситуаций, требующих героев. Не нужно ложиться грудью на амбразуру, если из неё никто не будет стрелять. При этом важно уметь тушить пожары – единоразовый фейл не должен рушить выстроенную систему.
Как недавно сказал наш СЕО – «есть люди, которые могут сделать хорошо, а есть те, которые не могут делать плохо». Стройте систему, чтобы быть вторыми.
Что полезнее, один раз сходить на пробежку в 15км и упасть от бессилия или регулярно 2 раза в неделю бегать по 3км? Прочитать «Войну и мир» или постоянно читать и заниматься самообразованием? Кто больше ценится в команде – тот, кто может «затащить» перед дедлайном, работая без передышек и задерживаясь на работе или тот, кто стабильно выдает крутой результат, заканчивая работать в 18:00?
Очевидно, что в долгосрочной перспективе, как для отдельно взятого человека, так и для команды побеждает система – меньше стресса, больше результатов, качество которых постоянно растёт. Да, ты можешь находиться на «пике» за счёт единоразовых сверхусилий или удачи, но через какое-то время ты оттуда слетишь, если не будет системы. Какой процент исполнителей, популярных позапрошлым летом ты помнишь сейчас? А какие гениальные стартапы, которые быстро взелетели 5 лет назад ещё существуют?
Система – это ускорение. Если ты двигаешься медленно, но с постоянным ускорением, через какое-то время ты обгонишь тех, кто уже сейчас двигается быстро, но с постоянной скоростью. Хочешь постоянно «лезть» вверх, ускоряясь?
Работая над системой, вместо постоянного решения возникающих проблем, можно избежать ситуаций, требующих героев. Не нужно ложиться грудью на амбразуру, если из неё никто не будет стрелять. При этом важно уметь тушить пожары – единоразовый фейл не должен рушить выстроенную систему.
Как недавно сказал наш СЕО – «есть люди, которые могут сделать хорошо, а есть те, которые не могут делать плохо». Стройте систему, чтобы быть вторыми.
Про потребление контента
Сложно представить современного человека, который не потребляет контент постоянно. Подкасты, статьи, видео. Часто это информация, которую даже нельзя применить здесь и сейчас. Так нужна ли она? Или это информационный мусор?
Знания можно уложить в 3 группы: первая безграничная – «не знаю, что не знаю». Там будет что-то, с чем вы никогда в жизни не сталкивались и проблемы, о существовании которых не подозреваете. Вторая – что-то, о чем вы слышали, но не можете сказать, что что-то в этом понимаете. И самая маленькая — вы знаете, что вы это знаете.
Весь профессиональный рост – это расширение зоны «знаю, что не знаю» и постепенное её заполнение «знаю, что знаю». На старте люди часто фокусируются на заполнении середины, не расширяя её. Отсюда и мемы в стиле
— Junior: я ничего не знаю
— Middle: я всё знаю
— Senior: я ничего не знаю, ну и ладно
Чтобы не попасть в ловушку «я все знаю» нужен баланс, насмотренность. Заглядывать в соседние технологии, понимать, чем занимаются люди вокруг, что используют, как. Если вдруг кажется, что вот теперь вы профессионал и во всем разобрались — есть плохие новости.
Постоянное потребление информации это ещё и источник идей. Не знаешь, что делать? Смотри, что делают другие. Создай систему для постоянного переваривания информации и совершенствуй ее — в помощь rss/reading lists/pocket и выделенное время в календаре. Лучше постоянный поток идей, чем их отсутствие.
Ведь ещё Ньютон говорил «То, что мы знаем - капля воды, то, чего мы не ведаем - целый океан, так что читай статейки»
Сложно представить современного человека, который не потребляет контент постоянно. Подкасты, статьи, видео. Часто это информация, которую даже нельзя применить здесь и сейчас. Так нужна ли она? Или это информационный мусор?
Знания можно уложить в 3 группы: первая безграничная – «не знаю, что не знаю». Там будет что-то, с чем вы никогда в жизни не сталкивались и проблемы, о существовании которых не подозреваете. Вторая – что-то, о чем вы слышали, но не можете сказать, что что-то в этом понимаете. И самая маленькая — вы знаете, что вы это знаете.
не знаю, что не знаю
┏━━━━━━━━━━━━━━━━━━━┓
┃знаю, что не знаю ┃
┃ ╔══════════════╗ ┃
┃ ║знаю, что знаю║ ┃
┃ ╚══════════════╝ ┃
┗━━━━━━━━━━━━━━━━━━━┛
Весь профессиональный рост – это расширение зоны «знаю, что не знаю» и постепенное её заполнение «знаю, что знаю». На старте люди часто фокусируются на заполнении середины, не расширяя её. Отсюда и мемы в стиле
— Junior: я ничего не знаю
— Middle: я всё знаю
— Senior: я ничего не знаю, ну и ладно
Чтобы не попасть в ловушку «я все знаю» нужен баланс, насмотренность. Заглядывать в соседние технологии, понимать, чем занимаются люди вокруг, что используют, как. Если вдруг кажется, что вот теперь вы профессионал и во всем разобрались — есть плохие новости.
Постоянное потребление информации это ещё и источник идей. Не знаешь, что делать? Смотри, что делают другие. Создай систему для постоянного переваривания информации и совершенствуй ее — в помощь rss/reading lists/pocket и выделенное время в календаре. Лучше постоянный поток идей, чем их отсутствие.
Ведь ещё Ньютон говорил «То, что мы знаем - капля воды, то, чего мы не ведаем - целый океан, так что читай статейки»
Лучший интерфейс — отсуствие интерфейса. Лучшее решение задачи — без написания кода. Умение использовать инструменты, которые упрощают вашу жизнь и позволяют удалить «инфрастуктурный» код из вашего продукта, сфокусироваться на решении бизнес-проблем – необходимый скилл любой команды.
Решил в нескольких частях рассказать про бесплатные инструменты, которые облегчают жизнь нашим командам разработки. В первой части про
– Newrelic
– Sentry
– Imgproxy
– Cloudflare
Решил в нескольких частях рассказать про бесплатные инструменты, которые облегчают жизнь нашим командам разработки. В первой части про
– Newrelic
– Sentry
– Imgproxy
– Cloudflare
Слова паразиты, часть 2
– Ну неужели самому трудно догадаться?
Второй триггер некачественных коммункаций в команде, после слова «нормально».
Объяснение ему – ошибка атрибуции, когда поведение других людей объясняется их личностными особенностями, а своё – внешними обстоятельствами. Если вдруг мне что-то непонятно, значит плохо задача поставлена, документация отстой, интерфейс не продумали и вообще, сложно догадаться, что мне сразу нужно больше информации? А если непонятно тому, с кем мы общаемся – то он просто не тянет, раз сам не догадался, что я имел ввиду. А работает эта ошибка в обе стороны в любых коммуникациях – члены команды, руководитель ↔ подчинённый, бизнес ↔ пользователь.
Как её избежать?
– Понять, что если закрадывается мысль «неужели ему самому трудно догадаться?» то так и есть – да, ему было трудно догадаться! Ведь он не обладает той информацией, которая есть в твоей голове! И это не его фейл, а твой
– Научиться ставить себя на чужое место. Это не так легко, как кажется – сложно убрать из головы ту информацию, которая в ней есть и представить свою реакцию без неё. Развивается только на практике
– Разговаривать. Это вообще главный инструмент для решения любых проблем в команде. Хочешь разобраться, понял ли тебя человек? Спроси, что именно он понял. Не понимаешь, что говорят тебе? Скажи об этом!
– Ну неужели самому трудно догадаться?
Второй триггер некачественных коммункаций в команде, после слова «нормально».
Объяснение ему – ошибка атрибуции, когда поведение других людей объясняется их личностными особенностями, а своё – внешними обстоятельствами. Если вдруг мне что-то непонятно, значит плохо задача поставлена, документация отстой, интерфейс не продумали и вообще, сложно догадаться, что мне сразу нужно больше информации? А если непонятно тому, с кем мы общаемся – то он просто не тянет, раз сам не догадался, что я имел ввиду. А работает эта ошибка в обе стороны в любых коммуникациях – члены команды, руководитель ↔ подчинённый, бизнес ↔ пользователь.
Как её избежать?
– Понять, что если закрадывается мысль «неужели ему самому трудно догадаться?» то так и есть – да, ему было трудно догадаться! Ведь он не обладает той информацией, которая есть в твоей голове! И это не его фейл, а твой
– Научиться ставить себя на чужое место. Это не так легко, как кажется – сложно убрать из головы ту информацию, которая в ней есть и представить свою реакцию без неё. Развивается только на практике
– Разговаривать. Это вообще главный инструмент для решения любых проблем в команде. Хочешь разобраться, понял ли тебя человек? Спроси, что именно он понял. Не понимаешь, что говорят тебе? Скажи об этом!
Правило бойскаута
В книге «Чистый код» Роберт Мартин призывает разработчиков пользоваться правилом бойскаута: оставляй место стоянки чище, чем оно было до твоего прихода. Интересный факт – если погуглить «правило бойскаута», то вы найдёте в основном ссылки на эту книгу.
Не важно, есть ли такое правило у бойскаутов или только у дяди Боба, суть его мне очень близка. Но его формулировка из книги мне не очень нравится – почему люди должны делать лучше только код? Мне ближе построение системы в голове – делай лучше всё, с чем работаешь. Тем более, что даже разработчики занимаются не только написанием кода.
Представь, что каждый в команде будет выполнять каждую свою задачу на 110%? Кроме того, что его просят – он будет ещё смотреть вокруг, искать несовершенства и предлагать улучшения (а иногда не предлагать, а сразу их реализовывать)? В процессах, документации, постановке целей, формате проведения собеседования, регламенте работы с клиентами, в коде, формате код-ревью, дизайне и используемых инструментах?
Может, именно из таких людей должны состоять продуктовые команды?
А как бы ты отнёсся к такой культуре?
💂 – это же хаос! Пусть все делают, что от них просят
🧘 – это уровень просвещения! Все рано или поздно к этому должны прийти!
В книге «Чистый код» Роберт Мартин призывает разработчиков пользоваться правилом бойскаута: оставляй место стоянки чище, чем оно было до твоего прихода. Интересный факт – если погуглить «правило бойскаута», то вы найдёте в основном ссылки на эту книгу.
Не важно, есть ли такое правило у бойскаутов или только у дяди Боба, суть его мне очень близка. Но его формулировка из книги мне не очень нравится – почему люди должны делать лучше только код? Мне ближе построение системы в голове – делай лучше всё, с чем работаешь. Тем более, что даже разработчики занимаются не только написанием кода.
Представь, что каждый в команде будет выполнять каждую свою задачу на 110%? Кроме того, что его просят – он будет ещё смотреть вокруг, искать несовершенства и предлагать улучшения (а иногда не предлагать, а сразу их реализовывать)? В процессах, документации, постановке целей, формате проведения собеседования, регламенте работы с клиентами, в коде, формате код-ревью, дизайне и используемых инструментах?
Может, именно из таких людей должны состоять продуктовые команды?
А как бы ты отнёсся к такой культуре?
💂 – это же хаос! Пусть все делают, что от них просят
🧘 – это уровень просвещения! Все рано или поздно к этому должны прийти!
Про внедрение процессов
Когда я начинал работать руководителем, я был уверен, что для организации любого нового процесса достаточно его описать словами и скинуть всем ссылку на это описание. Как я ошибался!
Любой процесс – это продукт, который нужно внедрить, а внедрение продуктов, в том числе внутренних – это не просто. Что нужно для внедрения?
– Продать идею людям. Какую их (а не вашу) проблему решает новый процесс?
– Сделать быстрый онбординг. Что прямо сейчас можно сделать, чтобы попробовать новый процесс и ощутить его пользу?
– Найти early-adopters. Соберите фидбек, доработайте
– Найти лидеров, которые введут новый процесс в свою работу. Кроме внедрения процесса у одного человека, он будет внедрён у целой команды.
– Проиллюстрировать процесс всеми возможными способами: про него нужно написать, рассказать, его нужно показать. Есть люди визуалы, есть аудиалы и т.д. – достучитесь до всех, до каждого своим способом.
А после этого – начните регулярно напоминать про новый процесс. И только когда вы устанете повторять – люди наконец-то вас услышат (с) CEO Linkedin Джефф Вейнер
Когда я начинал работать руководителем, я был уверен, что для организации любого нового процесса достаточно его описать словами и скинуть всем ссылку на это описание. Как я ошибался!
Любой процесс – это продукт, который нужно внедрить, а внедрение продуктов, в том числе внутренних – это не просто. Что нужно для внедрения?
– Продать идею людям. Какую их (а не вашу) проблему решает новый процесс?
– Сделать быстрый онбординг. Что прямо сейчас можно сделать, чтобы попробовать новый процесс и ощутить его пользу?
– Найти early-adopters. Соберите фидбек, доработайте
– Найти лидеров, которые введут новый процесс в свою работу. Кроме внедрения процесса у одного человека, он будет внедрён у целой команды.
– Проиллюстрировать процесс всеми возможными способами: про него нужно написать, рассказать, его нужно показать. Есть люди визуалы, есть аудиалы и т.д. – достучитесь до всех, до каждого своим способом.
А после этого – начните регулярно напоминать про новый процесс. И только когда вы устанете повторять – люди наконец-то вас услышат (с) CEO Linkedin Джефф Вейнер
Простой способ начать
Когда вы собираетесь сделать что-то новое, часто самое сложное – это начать. Это как белый лист для писателя – непонятно, что писать? Зато процесс разгоняется после первых строк.
Есть простая техника, которая упрощает первый шаг: не знаете, что вы хотите сделать? Подумайте, что вы точно не хотите – так вы сузите зону для старта.
– Не знаете, кого хотите нанять? Подумайте, кого вы не хотите видеть в команде
– Не знаете, как должно выглядеть новое приложение? Подумайте, как оно точно не должно выглядеть
– Не знаете, в чём ваши цели на следующий год? Подумайте, чем вы точно не хотите заниматься
Когда вы собираетесь сделать что-то новое, часто самое сложное – это начать. Это как белый лист для писателя – непонятно, что писать? Зато процесс разгоняется после первых строк.
Есть простая техника, которая упрощает первый шаг: не знаете, что вы хотите сделать? Подумайте, что вы точно не хотите – так вы сузите зону для старта.
– Не знаете, кого хотите нанять? Подумайте, кого вы не хотите видеть в команде
– Не знаете, как должно выглядеть новое приложение? Подумайте, как оно точно не должно выглядеть
– Не знаете, в чём ваши цели на следующий год? Подумайте, чем вы точно не хотите заниматься
Про планы и планирование
В любой компании, с разными подходами, размерами и людьми происходит примерно одно и тоже: руководство с менеджерами ставят планы, в которых они о чём-то забывают. В процессе работы возникают новые требования или происходят форс-мажоры и планы становятся не актуальными. Разработчики дают неверные оценки своей работы и планы менеджеров рушатся. Дизайнеры негодуют, что в правках их просят сделать то, что изначально вообще не обсуждалось – «Эу, мы же запланировали работы по дизайну и там этого не было!». В конце квартала менеджеры думают, как же так презентовать результаты, чтобы их планы считались выполнеными... Постоянный стресс и хаос! А казалось бы, планы созданы для душевного спокойствия и уменьшения энтропии...
Даже личные планы никогда не работают – когда ты последний раз запланировал свой день и занимался только тем, что написано в нём? И сделал всё, не больше и не меньше?
Так нужно ли что-то планировать или это лишнее усложнение, как в работе так и в жизни?
– Планирование – инструмент рефлексии. Обсуждая план (иногда – сам с собой) ты понимаешь, что именно собираешься делать. Поэтому план, опущенный сверху вниз без какого-либо обсуждения никогда не сработает. Слишком часто люди не понимают друг друга с первого раза
– План – вектор, а не конечная точка. И со временем этот вектор может меняться – не нужно подниматься на гору, если понял, что гора не та
– План с одной итерацией – плохой план. Парадокс: казалось бы, план должен составляться один раз в квартал/месяц/неделю/день и быть ориентиром. Но на самом деле, он должен в течение этого квартала/месяца/недели/дня постоянно обновляться
– Планирование – непрерывно совершенствующийся процесс. Просто начав планировать ты не начнёшь делать это хорошо. Например, в книге «Измеряйте самое важное» автор говорит, что для внедрения, казалось бы понятного способа планирования компаний Objectives & Key results (OKR) может понадобится 4–5 квартальных циклов.
В общем, «план – ничто, планирование – всё» Д. Эйзенхауэр
В любой компании, с разными подходами, размерами и людьми происходит примерно одно и тоже: руководство с менеджерами ставят планы, в которых они о чём-то забывают. В процессе работы возникают новые требования или происходят форс-мажоры и планы становятся не актуальными. Разработчики дают неверные оценки своей работы и планы менеджеров рушатся. Дизайнеры негодуют, что в правках их просят сделать то, что изначально вообще не обсуждалось – «Эу, мы же запланировали работы по дизайну и там этого не было!». В конце квартала менеджеры думают, как же так презентовать результаты, чтобы их планы считались выполнеными... Постоянный стресс и хаос! А казалось бы, планы созданы для душевного спокойствия и уменьшения энтропии...
Даже личные планы никогда не работают – когда ты последний раз запланировал свой день и занимался только тем, что написано в нём? И сделал всё, не больше и не меньше?
Так нужно ли что-то планировать или это лишнее усложнение, как в работе так и в жизни?
– Планирование – инструмент рефлексии. Обсуждая план (иногда – сам с собой) ты понимаешь, что именно собираешься делать. Поэтому план, опущенный сверху вниз без какого-либо обсуждения никогда не сработает. Слишком часто люди не понимают друг друга с первого раза
– План – вектор, а не конечная точка. И со временем этот вектор может меняться – не нужно подниматься на гору, если понял, что гора не та
– План с одной итерацией – плохой план. Парадокс: казалось бы, план должен составляться один раз в квартал/месяц/неделю/день и быть ориентиром. Но на самом деле, он должен в течение этого квартала/месяца/недели/дня постоянно обновляться
– Планирование – непрерывно совершенствующийся процесс. Просто начав планировать ты не начнёшь делать это хорошо. Например, в книге «Измеряйте самое важное» автор говорит, что для внедрения, казалось бы понятного способа планирования компаний Objectives & Key results (OKR) может понадобится 4–5 квартальных циклов.
В общем, «план – ничто, планирование – всё» Д. Эйзенхауэр
Издательство МИФ
Измеряйте самое важное (Джон Дорр) — купить в МИФе
Книга от основоположника OKR. Бумажная, электронная книга (epub, pdf, mobi, fb2), аудиокнига. Читать отзывы и скачать главу.
Лайфхак про планирование
Прочитал про него в «Джедайских техниках». Если задача постоянно переходит на следующий день/спринт/квартал – поменяй её формулировку. Из-за эффекта семантического насыщения ты со временем уделяешь ей меньше внимания (а иногда и хуже понимаешь, что же там нужно сделать)
Получается итеративная работа над формулировкой задачи, а чем понятнее формулировка – тем больше шанс выполнения.
Прочитал про него в «Джедайских техниках». Если задача постоянно переходит на следующий день/спринт/квартал – поменяй её формулировку. Из-за эффекта семантического насыщения ты со временем уделяешь ей меньше внимания (а иногда и хуже понимаешь, что же там нужно сделать)
Получается итеративная работа над формулировкой задачи, а чем понятнее формулировка – тем больше шанс выполнения.
Слова-паразиты, часть 3
– А давайте сделаем...!
Сколько раз в неделю вы слышите эту фразу в своей команде? А как часто говорите её? А какая конверсия из произнесения фразы в конечный результат? Подозреваю, что не очень высокая.
Эта фраза вызывает искажение: мы обсудили и произнесли вслух какое-то решение или идею, теперь она точно будет сделана! Но кто именно будет этим заниматься? И когда? А она важнее сотни других вещей или нет?
В такой формулировке фраза работает только с гипер-ответственными людьми, которые постоянно берут на себя всё больше. В других случаях произнося «а давайте сделаем...» держите в уме, что «сделаем» = «я сделаю».
Как повысить конверсию?
– Придумайте простой первый шаг. По каким бы критериям вы не приоритезировали задачи и идеи в команде, всё равно первыми будут сделаны понятные
– Решите, кто именно это сделает. Или проявите инициативу и явно выдвините свою кандидатуру. Это ещё и может послужить примером в будущем.
– Зафиксируйте идею/задачу в мессенджер/таск-менеджер. Даже если задача не будет сделана сразу – она не потеряется
– Иначе – не ожидайте результата. Ведь завышенные ожидания ведут к разочарованиям и выгораниям.
– А давайте сделаем...!
Сколько раз в неделю вы слышите эту фразу в своей команде? А как часто говорите её? А какая конверсия из произнесения фразы в конечный результат? Подозреваю, что не очень высокая.
Эта фраза вызывает искажение: мы обсудили и произнесли вслух какое-то решение или идею, теперь она точно будет сделана! Но кто именно будет этим заниматься? И когда? А она важнее сотни других вещей или нет?
В такой формулировке фраза работает только с гипер-ответственными людьми, которые постоянно берут на себя всё больше. В других случаях произнося «а давайте сделаем...» держите в уме, что «сделаем» = «я сделаю».
Как повысить конверсию?
– Придумайте простой первый шаг. По каким бы критериям вы не приоритезировали задачи и идеи в команде, всё равно первыми будут сделаны понятные
– Решите, кто именно это сделает. Или проявите инициативу и явно выдвините свою кандидатуру. Это ещё и может послужить примером в будущем.
– Зафиксируйте идею/задачу в мессенджер/таск-менеджер. Даже если задача не будет сделана сразу – она не потеряется
– Иначе – не ожидайте результата. Ведь завышенные ожидания ведут к разочарованиям и выгораниям.
Процесс разработки – это продукт
Часто разработчики думают, что продукт, получаемый в результате их работы совпадает с тем продуктом, который создаёт их компания. Всё так, но кроме этого они производят ещё и что-то внутреннее. Продукт, которым пользуется сама команда – весь процесс и код. А как нужно работать над продуктом?
– Двигайтесь итерациями. Не старайтесь сразу написать идеальный код и внедрить идеальные процессы, решить все проблемы
– Продумайте jobs to be done. Какие JTBD у вашей команды? Быстро выкатывать изменения на продакшен? Легко и просто тестировать изменения? Мониторить изменения на продакшене? А помогает ли это делать ваш продукт?
– UX должен решать проблемы. Для UX в коде/тулинге даже есть отдельный термин – Developer Experience / DX. Насколько легко и удобно пользоваться вашим процессом? Всё ли легко найти? А кодом? Проста ли навигация? Нет ли запутанных формулировок?
– Что по онбордингу? Intercom говорит, что онбординг должен вести пользователя до тех пор, пока он не получит value вашего продукта. Легко ли новичку запустить ваш проект и зарелизить своё первое изменение на прод в первый рабочий день?
– Следите за ключевыми метриками. Чтобы понять, улучшается или ухудшается ваш продукт нужно выделить ключевые метрики. Какие они для вас? Количество релизов в день? Строчки кода? Размер бандла на фронтенде? Скорость прогона тестов в CI?
Если взглянуть шире, то не только код или процесс, всё – продукт. Про это я немного поразмышлял на нашей внутренней конференции
Часто разработчики думают, что продукт, получаемый в результате их работы совпадает с тем продуктом, который создаёт их компания. Всё так, но кроме этого они производят ещё и что-то внутреннее. Продукт, которым пользуется сама команда – весь процесс и код. А как нужно работать над продуктом?
– Двигайтесь итерациями. Не старайтесь сразу написать идеальный код и внедрить идеальные процессы, решить все проблемы
– Продумайте jobs to be done. Какие JTBD у вашей команды? Быстро выкатывать изменения на продакшен? Легко и просто тестировать изменения? Мониторить изменения на продакшене? А помогает ли это делать ваш продукт?
– UX должен решать проблемы. Для UX в коде/тулинге даже есть отдельный термин – Developer Experience / DX. Насколько легко и удобно пользоваться вашим процессом? Всё ли легко найти? А кодом? Проста ли навигация? Нет ли запутанных формулировок?
– Что по онбордингу? Intercom говорит, что онбординг должен вести пользователя до тех пор, пока он не получит value вашего продукта. Легко ли новичку запустить ваш проект и зарелизить своё первое изменение на прод в первый рабочий день?
– Следите за ключевыми метриками. Чтобы понять, улучшается или ухудшается ваш продукт нужно выделить ключевые метрики. Какие они для вас? Количество релизов в день? Строчки кода? Размер бандла на фронтенде? Скорость прогона тестов в CI?
Если взглянуть шире, то не только код или процесс, всё – продукт. Про это я немного поразмышлял на нашей внутренней конференции
Intercom
Intercom Resources
Check out Intercom's resources on customer support, lead generation, customer engagement, and everything in between. No fluff or sales pitches. Just quality information and insights.
Проще = лучше
Наверняка, у каждого в школе или универе были преподаватели-антиподы. Первый был аспирант, объяснял «ковыряние в носу» с помощью сложных терминов, потом самоутверждался на экзаменах, унижая студентов, требуя заученных формулировок, вместо понимания. А в соседней аудитории кто-то весело и легко рассказывал про квантовую неопределённость, приводя в пример свою бабулю, которая смотрит Санта-Барбару. Или не смотрит. Какой предмет лучше усваивался? Уверен, что тот, который подавался простым и понятным языком.
В разработке есть принцип KISS – Keep it simple, stupid. Код нужно писать максимально просто и не усложнять без надобности. Чем проще код – тем проще его поддерживать, понимать, дописывать, изменять, переносить. А значит разработчики тратят меньше сил и нервов, а бизнес решает задачи быстрее и дешевле.
Но разработчику сложно написать простой код, если до него эффективный менеджер вместе с бизнес-аналитиком придумали гениальную гипотезу, усложняющую вообще всё, дизайнер наконец попробовал все самые модные тренды с дриббла, а тим-лид предложил заодно переписать всё на rust и наконец задеплоить в k8s.
Делать просто должен не разработчик, это командная работа. Старайтесь держать в уме этот принцип каждый раз, когда что-то создаёте – пишете код, документацию, задачу, пост, проектируете систему или рисуете дизайн. Чем проще – тем лучше. Не усложняйте. Не пытайтесь сразу сделать идеально. Сначала сделайте, а потом сделайте лучше. А когда сделаете несколько итераций – задумайтесь, а не усложнили ли вы всё? Парадоксально, но делать просто – сложно.
Решайте одну проблему в одну единицу времени. Вряд ли бы мы с вами сейчас попивали томатный сок на высоте 10км и пытались утрамбовать свой рюкзак гидравлическим прессом до размеров ручной клади в «Победе», если бы Да Винчи или братья Райт думали, как будут влиять самолёты на экологию и где в их летательных аппаратах будет располагаться клетка для перевозки домашних животных.
И помните, если у вас получается что-то очень сложное – вы делаете что-то не так.
Почитать по теме:
– Лонгрид про Overthinking от автора канал @uxlive. ⚠️ подача зайдёт не всем ⚠️
– Принцип Keep it simple, stupid
– Принцип Бритва Оккама
– Чем хуже, тем лучше
– Колхозная доктрина - KISS для разработчиков простым языком
P.S. Будет круто, если вы мне посоветуете книги/посты/видео по теме – пишите в комментарии
P.P.S. Давно не было цитат из пабликов в вк, исправляюсь: «Делай просто, насколько возможно, но не проще этого» А. Эйнштейн
Наверняка, у каждого в школе или универе были преподаватели-антиподы. Первый был аспирант, объяснял «ковыряние в носу» с помощью сложных терминов, потом самоутверждался на экзаменах, унижая студентов, требуя заученных формулировок, вместо понимания. А в соседней аудитории кто-то весело и легко рассказывал про квантовую неопределённость, приводя в пример свою бабулю, которая смотрит Санта-Барбару. Или не смотрит. Какой предмет лучше усваивался? Уверен, что тот, который подавался простым и понятным языком.
В разработке есть принцип KISS – Keep it simple, stupid. Код нужно писать максимально просто и не усложнять без надобности. Чем проще код – тем проще его поддерживать, понимать, дописывать, изменять, переносить. А значит разработчики тратят меньше сил и нервов, а бизнес решает задачи быстрее и дешевле.
Но разработчику сложно написать простой код, если до него эффективный менеджер вместе с бизнес-аналитиком придумали гениальную гипотезу, усложняющую вообще всё, дизайнер наконец попробовал все самые модные тренды с дриббла, а тим-лид предложил заодно переписать всё на rust и наконец задеплоить в k8s.
Делать просто должен не разработчик, это командная работа. Старайтесь держать в уме этот принцип каждый раз, когда что-то создаёте – пишете код, документацию, задачу, пост, проектируете систему или рисуете дизайн. Чем проще – тем лучше. Не усложняйте. Не пытайтесь сразу сделать идеально. Сначала сделайте, а потом сделайте лучше. А когда сделаете несколько итераций – задумайтесь, а не усложнили ли вы всё? Парадоксально, но делать просто – сложно.
Решайте одну проблему в одну единицу времени. Вряд ли бы мы с вами сейчас попивали томатный сок на высоте 10км и пытались утрамбовать свой рюкзак гидравлическим прессом до размеров ручной клади в «Победе», если бы Да Винчи или братья Райт думали, как будут влиять самолёты на экологию и где в их летательных аппаратах будет располагаться клетка для перевозки домашних животных.
И помните, если у вас получается что-то очень сложное – вы делаете что-то не так.
Почитать по теме:
– Лонгрид про Overthinking от автора канал @uxlive. ⚠️ подача зайдёт не всем ⚠️
– Принцип Keep it simple, stupid
– Принцип Бритва Оккама
– Чем хуже, тем лучше
– Колхозная доктрина - KISS для разработчиков простым языком
P.S. Будет круто, если вы мне посоветуете книги/посты/видео по теме – пишите в комментарии
P.P.S. Давно не было цитат из пабликов в вк, исправляюсь: «Делай просто, насколько возможно, но не проще этого» А. Эйнштейн
Слова-паразиты, часть 4
– Наверное, я скажу очевидную вещь...
Как давно вы хотели кому-то что-то сказать, но передумали, потому что это очевидно? Сколько фраз, сообщений, твитов, постов, докладов, анонсов в командах или компании вы не сделали из-за их очевидности?
А теперь вспомните последнюю прочитанную статью или книгу, из которой вы узнали что-то новое. Хочется ли вам об этом кому-то рассказать? Наверняка нет, ведь для вас это уже кажется простым и очевидным. А если бы так же размышлял автор и не поделился этим с вами?
Избыток информации лучше, чем её недостаток. В современном мире любой человек тренирует скилл фильтрации полезной для него информации, так что если он получит что-то лишнее – он просто отфильтрует это. Но если информацию он не получит – он может даже не узнать о её существовании и никакой скилл тут не поможет.
Каждый раз, когда вы говорите очевидную вещь, кто-то узнает что-то новое.
– Наверное, я скажу очевидную вещь...
Как давно вы хотели кому-то что-то сказать, но передумали, потому что это очевидно? Сколько фраз, сообщений, твитов, постов, докладов, анонсов в командах или компании вы не сделали из-за их очевидности?
А теперь вспомните последнюю прочитанную статью или книгу, из которой вы узнали что-то новое. Хочется ли вам об этом кому-то рассказать? Наверняка нет, ведь для вас это уже кажется простым и очевидным. А если бы так же размышлял автор и не поделился этим с вами?
Избыток информации лучше, чем её недостаток. В современном мире любой человек тренирует скилл фильтрации полезной для него информации, так что если он получит что-то лишнее – он просто отфильтрует это. Но если информацию он не получит – он может даже не узнать о её существовании и никакой скилл тут не поможет.
Каждый раз, когда вы говорите очевидную вещь, кто-то узнает что-то новое.
2 недели назад я писал про простоту. Но многим кажется, что это нерабочий подход и нельзя спешить, нужно всё продумывать, иначе нельзя сделать хороший и качественный продукт.
Но есть много кейсов, что это работает и можно делать крутые вещи в короткие сроки, фокусируясь на главном. Вот мои любимые примеры:
– Линус Торвальдс начал работу над git 3 апреля 2005 и уже 4 дня спустя он использовал git для работы над git чтобы коммитить в git, пока он создаёт git. А 20 апреля вышел первый релиз linux на git
– Кен Томпсон написал первую версию unix за 3 недели
– От решения полететь на луну до полёта Аполлон 8 прошло чуть больше 4 месяцев
– Брендан Эйх сделал первую версию JavaScript за N̶a̶N̶ 10 дней
Сохраняйте себе ссылку и скидывайте вашей команде разработки в следующий раз, когда они оценят очередную фичу в месяц
Но есть много кейсов, что это работает и можно делать крутые вещи в короткие сроки, фокусируясь на главном. Вот мои любимые примеры:
– Линус Торвальдс начал работу над git 3 апреля 2005 и уже 4 дня спустя он использовал git для работы над git чтобы коммитить в git, пока он создаёт git. А 20 апреля вышел первый релиз linux на git
– Кен Томпсон написал первую версию unix за 3 недели
– От решения полететь на луну до полёта Аполлон 8 прошло чуть больше 4 месяцев
– Брендан Эйх сделал первую версию JavaScript за N̶a̶N̶ 10 дней
Сохраняйте себе ссылку и скидывайте вашей команде разработки в следующий раз, когда они оценят очередную фичу в месяц
Слова-паразиты, часть 5
– Есть 5 минут?..
Знакомо? Сколько раз вы реально уложились? Смысл этой фразы всегда отличается от содержания – все понимают, что это не 5 минут, но продолжают использовать именно такую формулировку. Ведь так в голове есть оправдание – мы выдернули человека всего на чуть-чуть (даже если по факту разговаривали час)! Многие не умеют планировать время, даже своё.
– Цените чужое время. Тема на полчаса? Так и говорите, но планируйте заранее
– Не знаете, сколько нужно запланировать? Поставьте дедлайн. Не успеваете? Разбейте общение – у вас будет больше информации для планирования следующей встречи
– Цените своё время. Кто-то планирует с вами разговор на 5 минут? Поставьте таймер – это поможет держать фокус на главном. Не успели? Возможно, в следующий раз кто-то будет лучше ценить ваше время
– Говорите нет. Делаете что-то в потоке и вас хотят выдернуть? Пусть подождут. Минут 5.
– Не доверяйте людям, у которых всегда есть 5 минут.
– Есть 5 минут?..
Знакомо? Сколько раз вы реально уложились? Смысл этой фразы всегда отличается от содержания – все понимают, что это не 5 минут, но продолжают использовать именно такую формулировку. Ведь так в голове есть оправдание – мы выдернули человека всего на чуть-чуть (даже если по факту разговаривали час)! Многие не умеют планировать время, даже своё.
– Цените чужое время. Тема на полчаса? Так и говорите, но планируйте заранее
– Не знаете, сколько нужно запланировать? Поставьте дедлайн. Не успеваете? Разбейте общение – у вас будет больше информации для планирования следующей встречи
– Цените своё время. Кто-то планирует с вами разговор на 5 минут? Поставьте таймер – это поможет держать фокус на главном. Не успели? Возможно, в следующий раз кто-то будет лучше ценить ваше время
– Говорите нет. Делаете что-то в потоке и вас хотят выдернуть? Пусть подождут. Минут 5.
– Не доверяйте людям, у которых всегда есть 5 минут.
Первый шаг автоматизации – сделать это руками
Я фанат автоматизации всего и вся, но каждый раз, когда кто-то предлагает что-то запрограммировать, я спрашиваю – а сколько времени это занимает у человека? Часто оказывается, что проблема не во времени/сложности/частоте, а в том, что большинство людей хочет развивать продукты, повышать метрики и выполнять KPI, а рутинные задачи – не их уровень. Единственным решением они видят делегирование этих задач бездушной машине, которая не хочет карьерного роста и не будет говорить, что это не её обязанности.
Когда-то я подсмотрел у Леши идею создания специального отдела, в который кто угодно может делегировать простые задачи. Идея проста: вы нанимаете людей, которые занимаются только простыми/однообразными задачами, но делают это постоянно, тем самым разгружая остальные отделы. В итоге задачи делаются быстрее, стоят – дешевле. И часто экономят не только время менеджеров, но и разработчиков, т.к. отпадает нужда в автоматизации.
Какие задачи мы передаём в отдел?
– Сбор информации – ходить по сайтам, «парсить» тексты, копипасить в гугл-табличку или сохранять картинки на гугл-драйв
– Модерация (текстов, фотографий)
– Обработка данных, отчёты
– Простейшая работа с графикой
– Бонус 1: вы можете поставить задачу, которую сложно формализовать. Например «найди классные фотки», «выбери 20 самых интересных текстов»
– Бонус 2: этот человек обойдёт любую капчу!
В итоге не возникает вопросов «Кто бы мог заняться этой задачей?...» т.к. всегда есть выделенные люди. Задачи быстро берутся в работу, а их выполнение стоит дешевле, чем если бы ими занимались руководители.
В общем, всем рекомендую.
Я фанат автоматизации всего и вся, но каждый раз, когда кто-то предлагает что-то запрограммировать, я спрашиваю – а сколько времени это занимает у человека? Часто оказывается, что проблема не во времени/сложности/частоте, а в том, что большинство людей хочет развивать продукты, повышать метрики и выполнять KPI, а рутинные задачи – не их уровень. Единственным решением они видят делегирование этих задач бездушной машине, которая не хочет карьерного роста и не будет говорить, что это не её обязанности.
Когда-то я подсмотрел у Леши идею создания специального отдела, в который кто угодно может делегировать простые задачи. Идея проста: вы нанимаете людей, которые занимаются только простыми/однообразными задачами, но делают это постоянно, тем самым разгружая остальные отделы. В итоге задачи делаются быстрее, стоят – дешевле. И часто экономят не только время менеджеров, но и разработчиков, т.к. отпадает нужда в автоматизации.
Какие задачи мы передаём в отдел?
– Сбор информации – ходить по сайтам, «парсить» тексты, копипасить в гугл-табличку или сохранять картинки на гугл-драйв
– Модерация (текстов, фотографий)
– Обработка данных, отчёты
– Простейшая работа с графикой
– Бонус 1: вы можете поставить задачу, которую сложно формализовать. Например «найди классные фотки», «выбери 20 самых интересных текстов»
– Бонус 2: этот человек обойдёт любую капчу!
В итоге не возникает вопросов «Кто бы мог заняться этой задачей?...» т.к. всегда есть выделенные люди. Задачи быстро берутся в работу, а их выполнение стоит дешевле, чем если бы ими занимались руководители.
В общем, всем рекомендую.