Про nocode
Ещё с первых лет в айти меня постоянно преследовали инструменты разработки без написания кода. MS Frontpage, какое-то визуальное программирование в универе, потом – тильда и другие конструкторы. Но всегда я понимал, что это инструменты для тех, кто не может писать код, а я ИЛИТА – мне удобнее всё сделать самому – проще поддерживать, больше гибкости.
И вот в 2021 поймал себя на мысли, что начал регулярно пользоваться nocode-инструментами для решения задач, которые раньше бы запрограммировал
• Собрал для себя телеграмм-бота, помогающего вести бюджет. Он связывает телеграмм и табличку в google sheets.
• Используем integromat для наведения порядка на общем гугл-диске. Бот автоматически раскидывает видео демо по папкам с нужными правами + шлёт сообщения в слак каналы
• Сделали onboarding-бота через Slack workflows, который скидывает новичкам полезную инфу про компанию и ссылки
• Лучше подружили джиру и гихтаб с помощью jira automation – меняем лейблы в джире, чтобы понимать статусы пулл-реквестов, автоматически меняем статусы
Ещё с первых лет в айти меня постоянно преследовали инструменты разработки без написания кода. MS Frontpage, какое-то визуальное программирование в универе, потом – тильда и другие конструкторы. Но всегда я понимал, что это инструменты для тех, кто не может писать код, а я ИЛИТА – мне удобнее всё сделать самому – проще поддерживать, больше гибкости.
И вот в 2021 поймал себя на мысли, что начал регулярно пользоваться nocode-инструментами для решения задач, которые раньше бы запрограммировал
• Собрал для себя телеграмм-бота, помогающего вести бюджет. Он связывает телеграмм и табличку в google sheets.
• Используем integromat для наведения порядка на общем гугл-диске. Бот автоматически раскидывает видео демо по папкам с нужными правами + шлёт сообщения в слак каналы
• Сделали onboarding-бота через Slack workflows, который скидывает новичкам полезную инфу про компанию и ссылки
• Лучше подружили джиру и гихтаб с помощью jira automation – меняем лейблы в джире, чтобы понимать статусы пулл-реквестов, автоматически меняем статусы
Зачем разработчику уметь писать?
В большинстве продуктовых команд для опытного разработчика намного важнее софт-скилы, нежели hard. Один из таких скилов – написание текстов ✍️. Почему это важно?
• Вы понимаете, с кем разговариваете и о чём. Умея правильно сформулировать мысль вы предоставите максимум контекста и правильно зададите вопрос, не перегружая собеседника деталями, что сэкономит время обоим
• Вы лучше будете коммуницировать с остальной командой. Например, если что-то сломалось – мало написать «я починил». Важно предоставить необходимые детали – почему? Что мы сделали, чтобы это не ломалось потом? Это интересно не только разработчикам, а всей команде продукта
• Вы будете думать о «читателе» не только в текстах, но и в коде. Надевая шляпу «читателя» вашего собственного кода вы будете понимать, какие места в коде наименее понятны и предоставите необходимые детали, будете использовать правильное именование или добавите комметарии (не комментируя при этом каждую строчку кода)
• Будучи одновременно и человеком, который пишет код и который делает код-ревью вы облегчите задачу для ревьюера – аналогично коду вы предоставите необходимую информацию. Мы, например, используем шаблон для пулл-реквестов, чтобы разработчики не забывали про правильное описание
• Когда вы пишете текст, поясняя ваши действия, вы проводите своего рода ретроспективу проделанного. Часто на этом этапе можно понять, что на самом деле вы сделали не то, что хотели 🤔
• Парадоксально, но часто вы не сможете написать хороший код, если не можете написать хороший текст. Он может решать задачу, хорошо и быстро работать, но его будет трудно читать и поддерживать. Видели код, который пишут программисты-олимпиадники? А их тексты?
Как говорят в basecamp – если вы выбираете между двумя одинаковыми кандидатами – выбирайте того, который лучше пишет.
Считаете ли вы скилл написания текстов важным?
✍️ – да, нужно постоянно писать
🙅 – пустое описание, "fixed" в описании PR и погнали, некогда писать!
В большинстве продуктовых команд для опытного разработчика намного важнее софт-скилы, нежели hard. Один из таких скилов – написание текстов ✍️. Почему это важно?
• Вы понимаете, с кем разговариваете и о чём. Умея правильно сформулировать мысль вы предоставите максимум контекста и правильно зададите вопрос, не перегружая собеседника деталями, что сэкономит время обоим
• Вы лучше будете коммуницировать с остальной командой. Например, если что-то сломалось – мало написать «я починил». Важно предоставить необходимые детали – почему? Что мы сделали, чтобы это не ломалось потом? Это интересно не только разработчикам, а всей команде продукта
• Вы будете думать о «читателе» не только в текстах, но и в коде. Надевая шляпу «читателя» вашего собственного кода вы будете понимать, какие места в коде наименее понятны и предоставите необходимые детали, будете использовать правильное именование или добавите комметарии (не комментируя при этом каждую строчку кода)
• Будучи одновременно и человеком, который пишет код и который делает код-ревью вы облегчите задачу для ревьюера – аналогично коду вы предоставите необходимую информацию. Мы, например, используем шаблон для пулл-реквестов, чтобы разработчики не забывали про правильное описание
• Когда вы пишете текст, поясняя ваши действия, вы проводите своего рода ретроспективу проделанного. Часто на этом этапе можно понять, что на самом деле вы сделали не то, что хотели 🤔
• Парадоксально, но часто вы не сможете написать хороший код, если не можете написать хороший текст. Он может решать задачу, хорошо и быстро работать, но его будет трудно читать и поддерживать. Видели код, который пишут программисты-олимпиадники? А их тексты?
Как говорят в basecamp – если вы выбираете между двумя одинаковыми кандидатами – выбирайте того, который лучше пишет.
Считаете ли вы скилл написания текстов важным?
✍️ – да, нужно постоянно писать
🙅 – пустое описание, "fixed" в описании PR и погнали, некогда писать!
Сто раз отмерь, сто раз отрежь
Старая поговорка «сто раз отмерь, один раз отрежь» не работает в современной разработке. Неправильно отрезал – возьми новую доску. Нет времени планировать идеальный результат, потому что он таким не будет никогда. Нельзя ничего сделать идеально с первой попытки. Чем дольше делается первая версия – тем позже ты получишь инсайты о том, как можно сделать это лучше.
Долгие итерации негативно влияют и на твою мотивацию, и на уровень коммуникаций в команде. Почему?
1. Долго делаешь? Тебе тяжелее воспринимать негативный фидбек. Представь себе ситуацию, что ты делал что-то пол года но уже первый тест показал, что всё это не то и нужно идти в другом направлении. Сколько продлится твоя мини-депрессия?
2. Долго делаешь? Людям вокруг сложнее тебе сказать, что это можно сделать лучше, потому что см. п. 1. Вместо ориентации на продукт команда будет ориентироваться на эмпатию. «Ой, сейчас ему скажу, что можно было сделать по-другому и лучше, а он обидится – он же это 3 месяца делал. Лучше промолчу!». А что выберешь ты, сделать лучше продукт или не задеть чьи-то чувства? Так просто не ставь людей перед таким выбором.
3. Долго делаешь? Тебе сложнее держать фокус. Мотивация делать новый проект всегда выше, чем заканчивать что-то, начатое полгода назад. «Вот сейчас мы ещё чуть-чуть допилим и точно выкатимся!» – в 80% случаев ложь. Доделаете – придумаете, как сделать ещё лучше. И снова никто это не увидит. Кто любит делать что-то в стол?
4. Долго делаешь? Ты не делаешь другие вещи, а значит они простаивают. Или наоборот, ты делаешь их параллельно, теряя фокус с большой задачи
Как этого избежать?
• Используй правило OHIO – only hold it once. Сделай минимально рабочее решение, выкати его в прод и забудь о нём до следующей итерации. Либо у тебя будет новая цель для улучшения сделанного, либо сделаешь другую задачу/фичу/проект
• Декомпозируй. Раздели большой продукт/фичу на небольшие, но рабочие куски – так будет возможность в любой из промежуточных шагов уже выкатить всё на реальных пользователей. А долгосрочное видение поможет заложить правильную архитектуру для дальнейшего улучшения
• Отвечаешь за код? Чаще показывай и тестируй его
– Сразу открой pull request, коллеги будут делать ревью параллельно твоей работе и тебе сложно будет уйти не туда
– Чаще мёрж свои пулл-реквесты. Так не будет конфликтов и будет больше уверенности, что ничего нигде не сломалось
– Запланируй откат. Выкатить баг на прод – не проблема, проблема – не иметь возможности быстро его откатить или пофиксить.
• Отвечаешь за продукт? Чаще релизь
– Не уверен, что фича зайдёт пользователям? Выкати на небольшой процент аудитории
– Фича ещё не готова? Выключи её через feature toggle, пусть она ждёт своего часа в приложении
А какой философии придерживаешься ты?
🤔 – ну надо же всё продумать и сделать качественно
🚀 – быстро в прод
Старая поговорка «сто раз отмерь, один раз отрежь» не работает в современной разработке. Неправильно отрезал – возьми новую доску. Нет времени планировать идеальный результат, потому что он таким не будет никогда. Нельзя ничего сделать идеально с первой попытки. Чем дольше делается первая версия – тем позже ты получишь инсайты о том, как можно сделать это лучше.
Долгие итерации негативно влияют и на твою мотивацию, и на уровень коммуникаций в команде. Почему?
1. Долго делаешь? Тебе тяжелее воспринимать негативный фидбек. Представь себе ситуацию, что ты делал что-то пол года но уже первый тест показал, что всё это не то и нужно идти в другом направлении. Сколько продлится твоя мини-депрессия?
2. Долго делаешь? Людям вокруг сложнее тебе сказать, что это можно сделать лучше, потому что см. п. 1. Вместо ориентации на продукт команда будет ориентироваться на эмпатию. «Ой, сейчас ему скажу, что можно было сделать по-другому и лучше, а он обидится – он же это 3 месяца делал. Лучше промолчу!». А что выберешь ты, сделать лучше продукт или не задеть чьи-то чувства? Так просто не ставь людей перед таким выбором.
3. Долго делаешь? Тебе сложнее держать фокус. Мотивация делать новый проект всегда выше, чем заканчивать что-то, начатое полгода назад. «Вот сейчас мы ещё чуть-чуть допилим и точно выкатимся!» – в 80% случаев ложь. Доделаете – придумаете, как сделать ещё лучше. И снова никто это не увидит. Кто любит делать что-то в стол?
4. Долго делаешь? Ты не делаешь другие вещи, а значит они простаивают. Или наоборот, ты делаешь их параллельно, теряя фокус с большой задачи
Как этого избежать?
• Используй правило OHIO – only hold it once. Сделай минимально рабочее решение, выкати его в прод и забудь о нём до следующей итерации. Либо у тебя будет новая цель для улучшения сделанного, либо сделаешь другую задачу/фичу/проект
• Декомпозируй. Раздели большой продукт/фичу на небольшие, но рабочие куски – так будет возможность в любой из промежуточных шагов уже выкатить всё на реальных пользователей. А долгосрочное видение поможет заложить правильную архитектуру для дальнейшего улучшения
• Отвечаешь за код? Чаще показывай и тестируй его
– Сразу открой pull request, коллеги будут делать ревью параллельно твоей работе и тебе сложно будет уйти не туда
– Чаще мёрж свои пулл-реквесты. Так не будет конфликтов и будет больше уверенности, что ничего нигде не сломалось
– Запланируй откат. Выкатить баг на прод – не проблема, проблема – не иметь возможности быстро его откатить или пофиксить.
• Отвечаешь за продукт? Чаще релизь
– Не уверен, что фича зайдёт пользователям? Выкати на небольшой процент аудитории
– Фича ещё не готова? Выключи её через feature toggle, пусть она ждёт своего часа в приложении
А какой философии придерживаешься ты?
🤔 – ну надо же всё продумать и сделать качественно
🚀 – быстро в прод
5 блокеров для вашего развития
Недавно общался с нашим разработчиком про развитие и порефеклексировал на тему того, что мне мешало или наоборот, помогало в развитии как инженера. Пришёл к выводам, что часто замедляет развитие следующее:
1️⃣ Боязнь показаться некомпетентным. Часто амбиции и желание казаться умнее побеждают здравый смысл. Ты чего-то не понимаешь, но молчишь, потому что не хочешь в этом признаться. И чем дольше – тем сильнее это будет мешать. Если же всегда держать в уме, что ты чего-то не знаешь и это нормально – будет легче задавать вопросы. Спрашивай, ошибайся, даже тупи иногда! Ты никогда не будешь знать всё, но у тебя всегда будет шанс узнать что-то новое. Ты хочешь казаться топовым специалистом или быть им?
2️⃣ Ожидание, что тебя всему научат. Да, в больших компаниях могут помочь сделать personal development plan, там даже может быть внутренняя школа/академия, но только ты отвечаешь за своё обучение. Любой мой бывший одногруппник скажет, что 80% информации на факультете информатики ему ничего не дали, так почему образование в какой-то компании будет лучше? Ищи информацию, анализируй свои сильные и слабые стороны, проси фидбек от коллег и руководителей, понимай свои цели и «создавай» образовательный курс под себя, а не ожидай, что это кто-то сделает за тебя
3️⃣ Слепая вера авторитетам. «Тимлид сказал, что так делать нельзя». «Наш лучший бекендер говорит, что postgres лучше mysql». «В твиттере написали, что надо использовать redux». Инструменты развиваются. Ограничения устаревают. Почти для любого инструмента можно найти место, где он будет работать лучше самого популярного решения (а ещё это же утверждение справедливо для людей!). Лучшие умы не решали всех задач и не пробовали всё. «Оборотная сторона экспертов – то, что они слишком много знают о текущих ограничениях. Кто-то, взглянув свежим взглядом, может обойти эти ограничения практически благодаря своему невежеству» (с) Патти МакКорд – Сильнейшие. Анализируйте разные мнения, ищите противоположные точки зрения, задавайте вопросы!
4️⃣ Вера в то, что можно всему научиться по статьям. Статьи помогают решать проблемы и могут помочь ответить на конкретный вопрос. Но что делать, когда даже вопрос не известен? Книги помогают опуститься на другой уровень абстракции – они читаются дольше и с бóльшим погружением, часто они помогают задавать вопросы, но не дают ответов. Стековерфлоу помогает использовать чужие ответы, книги – давать свои.
5️⃣ Перекладывание ответственности. «Менеджер плохо сформулировал задачу», «На бекенеде сделали неправильное апи, не могу продолжать». Да, часто хочется написать такой коммент в jira/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!
А что из этого мешало вам?
Недавно общался с нашим разработчиком про развитие и порефеклексировал на тему того, что мне мешало или наоборот, помогало в развитии как инженера. Пришёл к выводам, что часто замедляет развитие следующее:
1️⃣ Боязнь показаться некомпетентным. Часто амбиции и желание казаться умнее побеждают здравый смысл. Ты чего-то не понимаешь, но молчишь, потому что не хочешь в этом признаться. И чем дольше – тем сильнее это будет мешать. Если же всегда держать в уме, что ты чего-то не знаешь и это нормально – будет легче задавать вопросы. Спрашивай, ошибайся, даже тупи иногда! Ты никогда не будешь знать всё, но у тебя всегда будет шанс узнать что-то новое. Ты хочешь казаться топовым специалистом или быть им?
2️⃣ Ожидание, что тебя всему научат. Да, в больших компаниях могут помочь сделать personal development plan, там даже может быть внутренняя школа/академия, но только ты отвечаешь за своё обучение. Любой мой бывший одногруппник скажет, что 80% информации на факультете информатики ему ничего не дали, так почему образование в какой-то компании будет лучше? Ищи информацию, анализируй свои сильные и слабые стороны, проси фидбек от коллег и руководителей, понимай свои цели и «создавай» образовательный курс под себя, а не ожидай, что это кто-то сделает за тебя
3️⃣ Слепая вера авторитетам. «Тимлид сказал, что так делать нельзя». «Наш лучший бекендер говорит, что postgres лучше mysql». «В твиттере написали, что надо использовать redux». Инструменты развиваются. Ограничения устаревают. Почти для любого инструмента можно найти место, где он будет работать лучше самого популярного решения (а ещё это же утверждение справедливо для людей!). Лучшие умы не решали всех задач и не пробовали всё. «Оборотная сторона экспертов – то, что они слишком много знают о текущих ограничениях. Кто-то, взглянув свежим взглядом, может обойти эти ограничения практически благодаря своему невежеству» (с) Патти МакКорд – Сильнейшие. Анализируйте разные мнения, ищите противоположные точки зрения, задавайте вопросы!
4️⃣ Вера в то, что можно всему научиться по статьям. Статьи помогают решать проблемы и могут помочь ответить на конкретный вопрос. Но что делать, когда даже вопрос не известен? Книги помогают опуститься на другой уровень абстракции – они читаются дольше и с бóльшим погружением, часто они помогают задавать вопросы, но не дают ответов. Стековерфлоу помогает использовать чужие ответы, книги – давать свои.
5️⃣ Перекладывание ответственности. «Менеджер плохо сформулировал задачу», «На бекенеде сделали неправильное апи, не могу продолжать». Да, часто хочется написать такой коммент в jira/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!
А что из этого мешало вам?
Про стандартизацию
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть 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 on Onboarding | Intercom Book
Onboarding isn’t a metric, it’s an outcome. This book shares the most valuable lessons we’ve learned from onboarding tens of thousands of customers.