Когда найм — это решение
Прямо сейчас в одной из моих команд происходит running to stay still. Это когда вы бежите изо всех сил, люди работают на совесть, делаете тонну задач — вы красавцы! Но заказчик все равно не очень доволен результатом и объемом сделанной работы.
Это плохая, но обычная ситуация. Почему она происходит?
Виды работы
Работа бывает нужная — это когда вы приносите бизнесу бабки, а бывает необходимая — это когда вы бабки не приносите, но спасаете бизнес от проблем. Например:
- Потратить несколько дней, чтобы оптимизировать запросы в БД
- Потратить неделю, чтобы переписать легаси-класс на три тысячи строк
- Потратить пару недель, чтобы обновить версию фреймворка
Чем старше проект, тем такой работы больше. Обобщенно такая штука называется "технический долг" и копится в любом проекте. И ее нужно делать, потому что если вы забьете на оптимизацию запросов, ваш сервис ляжет и бизнес заработает вообще ноль денег.
Другое дело, что бизнес не видит результата выплаты теходлга. Окей, вы потратили две недели, а сколько мы заработали?
Классификация
Вилл Ларсон в "Элегантном Пазле" предлагает категоризировать команды на 4 типа, исходя из отношения команды к техническому долгу:
- Falling behind — когда вы берете больше долга, чем отдаете, техдолг растет
- Running to stay still — новый долг по объему равен выплачиваемому, техдолг стагнирует
- Repaying Debt — платите больше, чем берете, техдолг снижается
- Innovating — для нашей темы неинтересно.
Что делать?
Нужно переходить из "running to stay still" в "repaying debt". Для этого перехода есть только два варианта, третьего нет.
- Нанять больше людей. Найм позволит вам расширить пул задач и начать платить больше. Для меня сейчас это не вариант, к сожалению.
- Делать меньше "нужной" работы и освободившееся время отдавать на выплату техдолга. Это мой вариант, но договориться с заказчиком будет не очень просто :)
Я, кстати, выступал на конфе по этому поводу
Прямо сейчас в одной из моих команд происходит running to stay still. Это когда вы бежите изо всех сил, люди работают на совесть, делаете тонну задач — вы красавцы! Но заказчик все равно не очень доволен результатом и объемом сделанной работы.
Это плохая, но обычная ситуация. Почему она происходит?
Виды работы
Работа бывает нужная — это когда вы приносите бизнесу бабки, а бывает необходимая — это когда вы бабки не приносите, но спасаете бизнес от проблем. Например:
- Потратить несколько дней, чтобы оптимизировать запросы в БД
- Потратить неделю, чтобы переписать легаси-класс на три тысячи строк
- Потратить пару недель, чтобы обновить версию фреймворка
Чем старше проект, тем такой работы больше. Обобщенно такая штука называется "технический долг" и копится в любом проекте. И ее нужно делать, потому что если вы забьете на оптимизацию запросов, ваш сервис ляжет и бизнес заработает вообще ноль денег.
Другое дело, что бизнес не видит результата выплаты теходлга. Окей, вы потратили две недели, а сколько мы заработали?
Классификация
Вилл Ларсон в "Элегантном Пазле" предлагает категоризировать команды на 4 типа, исходя из отношения команды к техническому долгу:
- Falling behind — когда вы берете больше долга, чем отдаете, техдолг растет
- Running to stay still — новый долг по объему равен выплачиваемому, техдолг стагнирует
- Repaying Debt — платите больше, чем берете, техдолг снижается
- Innovating — для нашей темы неинтересно.
Что делать?
Нужно переходить из "running to stay still" в "repaying debt". Для этого перехода есть только два варианта, третьего нет.
- Нанять больше людей. Найм позволит вам расширить пул задач и начать платить больше. Для меня сейчас это не вариант, к сожалению.
- Делать меньше "нужной" работы и освободившееся время отдавать на выплату техдолга. Это мой вариант, но договориться с заказчиком будет не очень просто :)
Я, кстати, выступал на конфе по этому поводу
Чтобы стать идеальным сотрудником, нужно всего лишь...
Самая важная часть работы менеджера — принимать решения. Чем больше у вас людей, тем больше решений вам надо принимать. Решения бывают разные: от того, в какую дату провести оффсайт команды, до выбора БД для real time аналитики на всю компанию.
С решениями есть проблема: в сутках 24 часа, из них рабочих в лучшем случае 10-12. Что же делать?
Рождение идеи
Американская военщина — источник не только многих бед, но и некоторых лучших ИТ практик. Например:
- SCRUM основан на цикле НОРД, который изобрели в армии США
- Extremal Ownership описан Джоко Вилинком, который служил в армии США
- Опрос 360 тоже появился в армии США!
В 1942-ом, в самый разгар Второй Мировой, полковник Арчер раз и навсегда ответил на вопрос: как должно выглядеть решение, которое нижестоящий офицер передаст вышестоящему. Арчер собрал свои мысли в статью и выпустил в свет "COMPLETED STAFF WORK" — шесть правил того, как выглядит завершенная работа.
Как должна выглядеть завершенная работа
1. Изучите проблему и представьте решение в таком виде, чтобы вышестоящий офицер мог только согласиться или отвергнуть ваше решение. Не добавляйте деталей и не перегружайте руководителя — разберитесь с нюансами сами или при помощи коллег.
2. Не спрашивайте вашего руководителя. Делайте свою работу сами и сами давайте ему советы.
3. Не беспокойте руководителя долгими объяснениями ситуации. Проанализируйте ситуацию, сделайте выводы, найдите выходы, выберите лучший и предложите решение, на которое можно ответить лишь "да" или "нет".
4. Никаких драфтов решений. Драфт отличается от финала лишь наличие помарок и опечаток.
5. Резонно потратить больше времени сотрудника, чтобы сэкономить время руководителя.
6. Спросите себя: если бы вы были руководителем, согласовали ли бы вы свое решение? Если нет — переделывайте.
Так чего же хочет руководитель
Он хочет дать вам задачу и вспомнить о ней только тогда, когда вы придете к нему с решением. Делайте так и быстро станете идеальным сотрудником.
Самая важная часть работы менеджера — принимать решения. Чем больше у вас людей, тем больше решений вам надо принимать. Решения бывают разные: от того, в какую дату провести оффсайт команды, до выбора БД для real time аналитики на всю компанию.
С решениями есть проблема: в сутках 24 часа, из них рабочих в лучшем случае 10-12. Что же делать?
Рождение идеи
Американская военщина — источник не только многих бед, но и некоторых лучших ИТ практик. Например:
- SCRUM основан на цикле НОРД, который изобрели в армии США
- Extremal Ownership описан Джоко Вилинком, который служил в армии США
- Опрос 360 тоже появился в армии США!
В 1942-ом, в самый разгар Второй Мировой, полковник Арчер раз и навсегда ответил на вопрос: как должно выглядеть решение, которое нижестоящий офицер передаст вышестоящему. Арчер собрал свои мысли в статью и выпустил в свет "COMPLETED STAFF WORK" — шесть правил того, как выглядит завершенная работа.
Как должна выглядеть завершенная работа
1. Изучите проблему и представьте решение в таком виде, чтобы вышестоящий офицер мог только согласиться или отвергнуть ваше решение. Не добавляйте деталей и не перегружайте руководителя — разберитесь с нюансами сами или при помощи коллег.
2. Не спрашивайте вашего руководителя. Делайте свою работу сами и сами давайте ему советы.
3. Не беспокойте руководителя долгими объяснениями ситуации. Проанализируйте ситуацию, сделайте выводы, найдите выходы, выберите лучший и предложите решение, на которое можно ответить лишь "да" или "нет".
4. Никаких драфтов решений. Драфт отличается от финала лишь наличие помарок и опечаток.
5. Резонно потратить больше времени сотрудника, чтобы сэкономить время руководителя.
6. Спросите себя: если бы вы были руководителем, согласовали ли бы вы свое решение? Если нет — переделывайте.
Так чего же хочет руководитель
Он хочет дать вам задачу и вспомнить о ней только тогда, когда вы придете к нему с решением. Делайте так и быстро станете идеальным сотрудником.
Как расти в карьере
Представьте Васю, он мидл-разработчик. Вася справляется со своими обязанностями и хочет расти до сеньора.
Вася думает: если я буду работать еще лучше, меня повысят. И Вася начинает сворачивать горы и показывает:
- Скиллы: берет самую тяжелую работу и вывозит
- Старательность: перерабатывает
- Результат: влезает в абсолютно все сроки
Но ни через месяц, ни через полгода, Васю не повышают.
Лучше всех в колхозе работала лошадь, но председателем она так и не стала, — думает Вася и теряет мотивацию.
Что случилось?
Руководитель не заметил, что Вася хочет вырасти. Руководитель заметил, что Вася отлично делает свою работу и точно находится на своем месте.
Почему руководитель не повысил Васю?
Много вариантов:
- Неопытный руководитель
- Слишком занятой руководитель, у которого нет времени анализировать реальность
- Руководитель-пофигист, который просто отбывает номер на проекте
Или руководитель — как раз о-о-очень опытная редиска и понимает, что если Васю повысить, придется искать на его позицию кого-то, кто будет работать не хуже. А где такого взять? Поэтому Вася будет сидеть на текущей позиции максимально долго и закрывать нужды редиски-руководителя.
А что делать?
Поговорить с руководителем на сессии один-на-один. Если ваш руководитель не проводит их регулярно, сами попросите поставить один-на-один.
На встрече голосом озвучьте ваши хотелки: до какой позиции хотите расти и за какое время. Например, Вася хотел вырасти от мидла до сеньора за полгода. Это невозможно, поэтому руководитель должен скорректировать ожидания Васи, после чего:
- Запланировать задачи "на рост" на работе.
- Подсветить точки роста Васи: посоветовать почитать Фаулера или кабанчика, например.
В идеале, у руководителя с Васей должна появится дорожная карта до нужной позиции, с которой они каждый месяц будут сверяться. В итоге, следуя плану, Вася получит нужный грейд и сохранит мотивацию работать.
Представьте Васю, он мидл-разработчик. Вася справляется со своими обязанностями и хочет расти до сеньора.
Вася думает: если я буду работать еще лучше, меня повысят. И Вася начинает сворачивать горы и показывает:
- Скиллы: берет самую тяжелую работу и вывозит
- Старательность: перерабатывает
- Результат: влезает в абсолютно все сроки
Но ни через месяц, ни через полгода, Васю не повышают.
Лучше всех в колхозе работала лошадь, но председателем она так и не стала, — думает Вася и теряет мотивацию.
Что случилось?
Руководитель не заметил, что Вася хочет вырасти. Руководитель заметил, что Вася отлично делает свою работу и точно находится на своем месте.
Почему руководитель не повысил Васю?
Много вариантов:
- Неопытный руководитель
- Слишком занятой руководитель, у которого нет времени анализировать реальность
- Руководитель-пофигист, который просто отбывает номер на проекте
Или руководитель — как раз о-о-очень опытная редиска и понимает, что если Васю повысить, придется искать на его позицию кого-то, кто будет работать не хуже. А где такого взять? Поэтому Вася будет сидеть на текущей позиции максимально долго и закрывать нужды редиски-руководителя.
А что делать?
Поговорить с руководителем на сессии один-на-один. Если ваш руководитель не проводит их регулярно, сами попросите поставить один-на-один.
На встрече голосом озвучьте ваши хотелки: до какой позиции хотите расти и за какое время. Например, Вася хотел вырасти от мидла до сеньора за полгода. Это невозможно, поэтому руководитель должен скорректировать ожидания Васи, после чего:
- Запланировать задачи "на рост" на работе.
- Подсветить точки роста Васи: посоветовать почитать Фаулера или кабанчика, например.
В идеале, у руководителя с Васей должна появится дорожная карта до нужной позиции, с которой они каждый месяц будут сверяться. В итоге, следуя плану, Вася получит нужный грейд и сохранит мотивацию работать.
Пять неочевидных способов усложнить себе интервью
Был период, когда я проводил по 3-4 собеседования в день. Каждый день. Со временем, глаз начал цепляться за неочевидные детали. Я называю их "оранжевый флаг" — не критичный, но неприятный момент в ходе интервью. Наличие оранжевого флага не означает провал интервью, но лучше их свести в ноль.
1️⃣ Не спросить ничего самому. В конце интервью я выделяю время на вопросы соискателя. Мне важно, что интересно человеку и о чем он меня спросит: про атмосферу в команде, переработки или отношение к срокам. Если у человека в конце нет вопросов, я вижу этот как толику безразличия к будущему месту работы.
2️⃣ Слишком много говорить. Некоторых соискателей я постоянно перебивал и прерывал, потому что они уходил в дебри вопроса. Не поймите меня неправильно: подробный ответ — это хорошо, но важно придерживаться сути вопроса и не уходить за горизонт. Например, на вопрос "Зачем вы использовали Кафку?" я не очень хочу услышать лекцию про Raft или распределенные системы.
3️⃣ Слишком мало говорить. Если мне приходится вытягивать из соискателя ответы, это тоже плохой признак: возможно, ему не очень интересна вакансия. На тот же вопрос "Зачем вы использовали Кафку" лучше отвечать подробнее, чем просто "Понравилось". Иногда за неинформативными ответами прячется тот факт, что соискатель ничего сам руками и не делал, просто рядом стоял, но пытается выдать чужие достижения за свои.
4️⃣ Говорить на бегу, в машине или в где-то в подъезде. Все три случая я взял из практики. Я понимаю, что обстоятельства бывают разные, но лучше все-таки перенести собеседование.
5️⃣ Выдумывать, гадать и привирать. Нет ничего плохого сказать "Я не знаю ответа на твой вопрос". Я в таких случаях предлагаю подумать вместе и даже подскажу. Однако, если это превращается в угадайку или "Не помню Кафку, давно ее не использовал, но вообще — очень хорошо знаю!", для меня это оранжевый флаг. Нельзя знать все, но плохо думать, что знаешь все.
Какие неочевидные оранжевые флаги вы подмечаете у соискателей?
Был период, когда я проводил по 3-4 собеседования в день. Каждый день. Со временем, глаз начал цепляться за неочевидные детали. Я называю их "оранжевый флаг" — не критичный, но неприятный момент в ходе интервью. Наличие оранжевого флага не означает провал интервью, но лучше их свести в ноль.
1️⃣ Не спросить ничего самому. В конце интервью я выделяю время на вопросы соискателя. Мне важно, что интересно человеку и о чем он меня спросит: про атмосферу в команде, переработки или отношение к срокам. Если у человека в конце нет вопросов, я вижу этот как толику безразличия к будущему месту работы.
2️⃣ Слишком много говорить. Некоторых соискателей я постоянно перебивал и прерывал, потому что они уходил в дебри вопроса. Не поймите меня неправильно: подробный ответ — это хорошо, но важно придерживаться сути вопроса и не уходить за горизонт. Например, на вопрос "Зачем вы использовали Кафку?" я не очень хочу услышать лекцию про Raft или распределенные системы.
3️⃣ Слишком мало говорить. Если мне приходится вытягивать из соискателя ответы, это тоже плохой признак: возможно, ему не очень интересна вакансия. На тот же вопрос "Зачем вы использовали Кафку" лучше отвечать подробнее, чем просто "Понравилось". Иногда за неинформативными ответами прячется тот факт, что соискатель ничего сам руками и не делал, просто рядом стоял, но пытается выдать чужие достижения за свои.
4️⃣ Говорить на бегу, в машине или в где-то в подъезде. Все три случая я взял из практики. Я понимаю, что обстоятельства бывают разные, но лучше все-таки перенести собеседование.
5️⃣ Выдумывать, гадать и привирать. Нет ничего плохого сказать "Я не знаю ответа на твой вопрос". Я в таких случаях предлагаю подумать вместе и даже подскажу. Однако, если это превращается в угадайку или "Не помню Кафку, давно ее не использовал, но вообще — очень хорошо знаю!", для меня это оранжевый флаг. Нельзя знать все, но плохо думать, что знаешь все.
Какие неочевидные оранжевые флаги вы подмечаете у соискателей?
Что влияет на продуктивность работы программиста? Исследователи взяли 600 человек из 92 компаний, разбили их на пары, выдали им одинаковое задание на день и попросили отмечать время.
❌ Что не влияет на продуктивность
- Язык разработки: COBOL и Fortran не особо отличались от С. Единственное исключение — языки Ассемблера.
- Опыт: разработчики с опытом в десять лет справились не лучше коллег, которые работали пару лет.
- Итоговое качество: около 30% программистов не допустили ни единого бага, при этом они потратили столько же времени.
- Зарплата: разброс результатов внутри одной вилки не особо отличался от общего разброса.
Замечу: мы говорим о задании "на день", так что кодовая база проекта будет маленькой и разница между языками действительно не очень заметна. Чем больше проект, тем больше решает язык — мое мнение.
✔️ Что влияет на продуктивность
Главным фактором эффективности программиста стала... Его компания. В каких-то компаниях программисты показывали стабильно хороший результат, в других — стабильно плохой. Если 9 программистов компании хорошо себя показали, можно с уверенностью заявить, что и 10-ый будет хорош — и наоборот!
В лучших компаниях разработчики показывали результат в 11 раз лучше, чем в плохой. В одиннадцать раз!
Но ведь мы говорим про конкретное задание, так что разница в процессах типа канбана, скрама, аджайла и вотерфолла роли тут играть не будет. Откуда такая разница?
Исследователи пришли к выводу, что разница крылась в рабочем месте. Вот основные критерии "успеха" по их мнению:
- Физический размер рабочего пространства
- Тишина на рабочем месте
- Приватность рабочего места: ну знаете, когда никто не ходит мимо и не смотрит в твой экран
- Возможность отказаться от созвона
- Количество прерываний в работе: от вопроса в личку до предложения сгонять за кофе
Мое мнение
Рабочее место важно, но я уверен, что не оно определяет продуктивность. Мне нравится мысль про то, что успех определяет компания, но я говорю о процессах и культуре.
А вы что скажете, от чего зависит эффективность разработки?
- Язык разработки: COBOL и Fortran не особо отличались от С. Единственное исключение — языки Ассемблера.
- Опыт: разработчики с опытом в десять лет справились не лучше коллег, которые работали пару лет.
- Итоговое качество: около 30% программистов не допустили ни единого бага, при этом они потратили столько же времени.
- Зарплата: разброс результатов внутри одной вилки не особо отличался от общего разброса.
Замечу: мы говорим о задании "на день", так что кодовая база проекта будет маленькой и разница между языками действительно не очень заметна. Чем больше проект, тем больше решает язык — мое мнение.
Главным фактором эффективности программиста стала... Его компания. В каких-то компаниях программисты показывали стабильно хороший результат, в других — стабильно плохой. Если 9 программистов компании хорошо себя показали, можно с уверенностью заявить, что и 10-ый будет хорош — и наоборот!
В лучших компаниях разработчики показывали результат в 11 раз лучше, чем в плохой. В одиннадцать раз!
Но ведь мы говорим про конкретное задание, так что разница в процессах типа канбана, скрама, аджайла и вотерфолла роли тут играть не будет. Откуда такая разница?
Исследователи пришли к выводу, что разница крылась в рабочем месте. Вот основные критерии "успеха" по их мнению:
- Физический размер рабочего пространства
- Тишина на рабочем месте
- Приватность рабочего места: ну знаете, когда никто не ходит мимо и не смотрит в твой экран
- Возможность отказаться от созвона
- Количество прерываний в работе: от вопроса в личку до предложения сгонять за кофе
Мое мнение
Рабочее место важно, но я уверен, что не оно определяет продуктивность. Мне нравится мысль про то, что успех определяет компания, но я говорю о процессах и культуре.
А вы что скажете, от чего зависит эффективность разработки?
Please open Telegram to view this post
VIEW IN TELEGRAM
DORA — это DevOps Report, группа людей, которые опрашивают сотрудников крупных компаний на тему "как у вас устроено ИТ в целом и DevOps в частности". Потом ответы собирают, анализируют и делают выводы.
Оригинальный отчет занимает 60 страниц, поэтому вот вам краткие lessons learned из отчета за 2023 год.
1️⃣ Самый легкий способ ускорить вашу разработку — ускорить ваше code review.
Я лично видел, как у команды было нормой ревьюить коммит 2-3 дня. То есть: человек пишет код 3-4 часа, тестирует его минут 30, а потом ждет трое суток (72 часа, кстати), пока кто-то сделает ревью.
Итого: вместо 5 часов заказчик ждет задачу 77 часов.
2️⃣ Найдите баланс между скоростью и стабильностью.
Подчеркну — баланс. Инциденты в проде — ок, не старайтесь свести их в нулю. Чем больше сил вы вкладываете в стабильность, тем меньше результата вы получите.
Тот же Netflix вообще открыто заявляет, что готов принести в жертву стабильность ради скорости. Netflix понимает, что на их рынке скорость поставки новых фич — лучший способ удержать клиента и рынок. Если Netflix будет мега-стабильным, но не таким прорывным, он потеряет рынок.
3️⃣ Распределяйте работу равномерно.
Не допускайте, чтобы все интересные задачи скидывали на какого-то крутого бойца, а всю рутину разгребал замученный и демотивированный мидл.
В Pixar говорят, что всем их работникам порой нужно "покормить зверя". Под зверем Pixar понимает творческое начинание внутри каждого из вас. Если время от времени не подкидывать нашему творцу задачек, мы начинаем выгорать.
Я где-то с 2017 года работаю без отпуска, но к выгоранию даже близко не подошел — постоянная смена задач и новые вызовы поддерживают интерес к работе.
Если есть время — почитайте отчет целиком
Там и про фокус на клиенте, и про корреляцию заработка и частоты деплоев, и даже про культуру есть.
Оригинальный отчет занимает 60 страниц, поэтому вот вам краткие lessons learned из отчета за 2023 год.
1️⃣ Самый легкий способ ускорить вашу разработку — ускорить ваше code review.
Я лично видел, как у команды было нормой ревьюить коммит 2-3 дня. То есть: человек пишет код 3-4 часа, тестирует его минут 30, а потом ждет трое суток (72 часа, кстати), пока кто-то сделает ревью.
Итого: вместо 5 часов заказчик ждет задачу 77 часов.
2️⃣ Найдите баланс между скоростью и стабильностью.
Подчеркну — баланс. Инциденты в проде — ок, не старайтесь свести их в нулю. Чем больше сил вы вкладываете в стабильность, тем меньше результата вы получите.
Тот же Netflix вообще открыто заявляет, что готов принести в жертву стабильность ради скорости. Netflix понимает, что на их рынке скорость поставки новых фич — лучший способ удержать клиента и рынок. Если Netflix будет мега-стабильным, но не таким прорывным, он потеряет рынок.
3️⃣ Распределяйте работу равномерно.
Не допускайте, чтобы все интересные задачи скидывали на какого-то крутого бойца, а всю рутину разгребал замученный и демотивированный мидл.
В Pixar говорят, что всем их работникам порой нужно "покормить зверя". Под зверем Pixar понимает творческое начинание внутри каждого из вас. Если время от времени не подкидывать нашему творцу задачек, мы начинаем выгорать.
Я где-то с 2017 года работаю без отпуска, но к выгоранию даже близко не подошел — постоянная смена задач и новые вызовы поддерживают интерес к работе.
Если есть время — почитайте отчет целиком
Там и про фокус на клиенте, и про корреляцию заработка и частоты деплоев, и даже про культуру есть.
Смешной мем, подумали вы? Реальность для тысяч IT-шников, отвечу я. Если для вас это тоже жиза, читайте дальше.
Я работал в компании четыре года на позиции линейного/ведущего разработчика. И примерно три года из четырех я думал, что меня скоро уволят. Я серьезно: я приходил на работу и думал, что вот-вот, вот-вот всю поймут, что я хреновый разраб и меня кикнут.
Когда я все-таки ушел из компании, мой руководитель на прощальном мите сказал, что очень расстроен и что без меня будет сильно хуже.
То есть: меня не хотели уволить. Меня хотели удерживать! Как так получилось?
❓ Почему мы думаем, что нас завтра уволят
Потому что не можем объективно оценить реальность из-за следующих причин:
- Высокие требования к себе. Я вижу каждую свою ошибку и вижу результаты своей работы. Они не идеальны.
- Синдром самозванца, когда нам кажется, что нас по ошибке взяли на нашу роль.
- Видимый (лишь видимый!) успешный успех коллег вокруг вас. Их провалы вы не видите, поэтому вам кажется, что вся их работа — это успех.
Плохие новости: у вас не получится снизить требования к себе (пробовал, знаю) и от синдрома самозванца избавиться не выйдет.
Еще хуже: подобные мысли вызывают хронический стресс и кучу адовых проблем со здоровьем. Так что же делать?
💡 Объективно оценить реальность
Самый верный способ избавиться от мысли про "я плохой, меня уволят" — поговорить с вашим руководителем. Опытный руководитель сам донесет до вас удовлетворенность вашей работой, но если вдруг не доносит, спросите сами!
Если же вы руководитель, отчетливо проговорите, довольны ли вы вашим сотрудником. Если довольны — почему, если нет — как исправить и что будет, если сотрудник не примет исправления.
Идеальное время для такого вопроса — ваш 1-1 с руководителем. У меня в командах принято ставить 1-1 регулярно, один раз в одну-две недели, в зависимости от ситуации. Если у вас нет 1-1 с руководителем, это — само по себе проблема. Попросите его поставить такую встречу.
P.S. Если вы решили проблему как-то по-другому, напишите. Мне правда интересно.
Я работал в компании четыре года на позиции линейного/ведущего разработчика. И примерно три года из четырех я думал, что меня скоро уволят. Я серьезно: я приходил на работу и думал, что вот-вот, вот-вот всю поймут, что я хреновый разраб и меня кикнут.
Когда я все-таки ушел из компании, мой руководитель на прощальном мите сказал, что очень расстроен и что без меня будет сильно хуже.
То есть: меня не хотели уволить. Меня хотели удерживать! Как так получилось?
Потому что не можем объективно оценить реальность из-за следующих причин:
- Высокие требования к себе. Я вижу каждую свою ошибку и вижу результаты своей работы. Они не идеальны.
- Синдром самозванца, когда нам кажется, что нас по ошибке взяли на нашу роль.
- Видимый (лишь видимый!) успешный успех коллег вокруг вас. Их провалы вы не видите, поэтому вам кажется, что вся их работа — это успех.
Плохие новости: у вас не получится снизить требования к себе (пробовал, знаю) и от синдрома самозванца избавиться не выйдет.
Еще хуже: подобные мысли вызывают хронический стресс и кучу адовых проблем со здоровьем. Так что же делать?
💡 Объективно оценить реальность
Самый верный способ избавиться от мысли про "я плохой, меня уволят" — поговорить с вашим руководителем. Опытный руководитель сам донесет до вас удовлетворенность вашей работой, но если вдруг не доносит, спросите сами!
Если же вы руководитель, отчетливо проговорите, довольны ли вы вашим сотрудником. Если довольны — почему, если нет — как исправить и что будет, если сотрудник не примет исправления.
Идеальное время для такого вопроса — ваш 1-1 с руководителем. У меня в командах принято ставить 1-1 регулярно, один раз в одну-две недели, в зависимости от ситуации. Если у вас нет 1-1 с руководителем, это — само по себе проблема. Попросите его поставить такую встречу.
P.S. Если вы решили проблему как-то по-другому, напишите. Мне правда интересно.
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет!
Мы тут вернулись с новым выпуском, теперь — в формате шоу! Обсуждаем собеседования, красные флаги кандидатов и компаний, играем в игры. Задаем вопросы нашей гостье, которая хантит СТО, где еще есть такой контент?)
В конце бонус от меня: история найма от Древнего Рима до наших дней.
https://youtu.be/jgRZ-wI50xs?si=i-G3qAhdFh6i698J
Буду рад обратной связи :)
Мы тут вернулись с новым выпуском, теперь — в формате шоу! Обсуждаем собеседования, красные флаги кандидатов и компаний, играем в игры. Задаем вопросы нашей гостье, которая хантит СТО, где еще есть такой контент?)
В конце бонус от меня: история найма от Древнего Рима до наших дней.
https://youtu.be/jgRZ-wI50xs?si=i-G3qAhdFh6i698J
Буду рад обратной связи :)
YouTube
Найм в IT. Как не провалить собеседование? Шоу «Для Tech и этих» #1
Новый сезон — новый формат! Теперь «Для tech и этих» — не просто подкаст, а настоящее IT-шоу! Любимые ведущие обсуждают больные темы из мира IT с гостями, делятся опытом, ищут лайфхаки и играют в игры.
В первом выпуске Олег Федоткин, Семён Мацепура и Дима…
В первом выпуске Олег Федоткин, Семён Мацепура и Дима…
Инженер и Менеджер
Привет! Меня давно не было на связи, но я приготовил для вас нечто уникальное: серию мини-статей про стиль управления руководителей прошлого. Я уверен, что у Черчилля, Наполеона, Цезаря и Хидэеси есть, чему поучиться. Первая серия будет посвящена Тойотоми…
Про лидера
Помните, мы с вами говорили про Тоётоми Хидэеси? Давайте продолжим.
Тоётоми получил задачу: ускорить ремонт одного из замков на границе. Шла война, так что огромная дыра в стене замка была не очень кстати. Сроки по ремонту были неоднократно сорваны, так что Тоётоми должен был заменить начальника и починить стену за три дня.
Тоётоми прибыл на место и приуныл: ремонт стены шел отвратительно. Люди работали неохотно, и с таким темпом ремонт не удалось бы закончить ни за три дня, ни даже за неделю. Начальник постоянно кричал и бил рабочих, но ремонт быстрее не шел и начальник валил все провалы на подчиненных.
Классика! Ситуация знакома любому менеджеру: тебе достался проект с горящими сроками и команда, которая уже давно опустила руки и открыла резюме для поиска работы. Типичный начальник попробует:
❌ Кричать громче и "бить" людей сильнее. Такие "руководители" быстро теряют людей, ломают коллектив и дальше наперегонки: либо успеют уволиться ПСЖ, либо их выкинут за провал.
❌ Увольнять людей за низкий уровень продуктивности, а вышестоящему руководству говорить, что виновата команда. Рано или поздно такого "руководителя" и самого уволят, но вреда он наделает много.
❌ "Прошаренные" постараются залить проект людьми. Это не сработает, говорит нам закон Брукса.
Ничего из перечисленного настоящий лидер не сделает.
Для начала Тоётоми собрал всех и... Забухал. Я серьезно: он повелел выкатить почти рисовой водки, риса и прочей самурайской еды. Все это творческий коллектив употребил под хохот и веселье, после чего ушел спать.
На следующий день Тоётоми собрал всех и вновь озвучил цель. После, Тоётоми разделил людей на команды и пообещал самым исполнительным дополнительную награду сверх положенной платы.
Дальше Тоётоми не ушел к себе в шатер, а находился среди рабочих: контролировал, советовал и даже помогал собственными руками.
Рабочие с под руководством лидера уложились в срок, получили награду, а Тоётоми — признание Оды Нобунаги.
Я вижу здесь три главных вывода:
✔️ Начальник просто ставит цель. Лидер обеспечивает результат.
✔️ Начальник требует невозможного. Лидер не требует ничего, чего не сделал бы сам.
✔️ Мораль коллектива прежде всего. Я не видел ни одного слаженного коллектива, которые завалил бы задачу. Я не видел блестящих результатов от разваленной команды.
Помните, мы с вами говорили про Тоётоми Хидэеси? Давайте продолжим.
Тоётоми получил задачу: ускорить ремонт одного из замков на границе. Шла война, так что огромная дыра в стене замка была не очень кстати. Сроки по ремонту были неоднократно сорваны, так что Тоётоми должен был заменить начальника и починить стену за три дня.
Тоётоми прибыл на место и приуныл: ремонт стены шел отвратительно. Люди работали неохотно, и с таким темпом ремонт не удалось бы закончить ни за три дня, ни даже за неделю. Начальник постоянно кричал и бил рабочих, но ремонт быстрее не шел и начальник валил все провалы на подчиненных.
Классика! Ситуация знакома любому менеджеру: тебе достался проект с горящими сроками и команда, которая уже давно опустила руки и открыла резюме для поиска работы. Типичный начальник попробует:
Ничего из перечисленного настоящий лидер не сделает.
Для начала Тоётоми собрал всех и... Забухал. Я серьезно: он повелел выкатить почти рисовой водки, риса и прочей самурайской еды. Все это творческий коллектив употребил под хохот и веселье, после чего ушел спать.
На следующий день Тоётоми собрал всех и вновь озвучил цель. После, Тоётоми разделил людей на команды и пообещал самым исполнительным дополнительную награду сверх положенной платы.
Дальше Тоётоми не ушел к себе в шатер, а находился среди рабочих: контролировал, советовал и даже помогал собственными руками.
Рабочие с под руководством лидера уложились в срок, получили награду, а Тоётоми — признание Оды Нобунаги.
Я вижу здесь три главных вывода:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Oleg Fedotkin
Пропадал надолго, исправляюсь — смотрите, что я вам принес! Пробегитесь по скриншотам и переходите к посту. Я не согласен с каждым тезисом до единого.
1️⃣ Первое, оно же главное — руководитель гораздо чаще хочет "стать друзьями" с подчиненными, чтобы насыпать им в панамку побольше работы. В ИТ реже, вне ИТ чаще бывает такое, что руководитель "лезет под кожу" подчиненным, пытается сойти за своего парня, чтобы получить больше возможности для манипуляций. Я пока еще ни одного руководителя не видел, которым подчиненные манипулировали.
2️⃣ Второе: если вы наняли людей, которые пользуются чужой добротой, вам надо учиться нанимать людей. Причем без разницы, эксплуатируют вашу доброту или чужую, таких нанимать не нужно, таких нужно увольнять. Вообще, нужно постараться, чтобы таких нанять.
3️⃣ Третье: реципрокность. Это очень, очень мощный механизм внутри каждого из нас, который на любую оказанную нам услугу требует у нас оказать услугу в ответ. Если механизм сломан, это сигнализирует об отклонениях, например — социопатии. Если руководитель оказывает услугу сотруднику, сотрудник окажет ее в ответ в 9 случаях из 10.
В общем, текст рекламы направлен на неуверенных в себе руководителях, которые почему-то хотят держать коллектив "шелковыми". Я б от такого ушел поскорее.
Моя история успеха — это как раз хороший коллектив друзей (friend'ов, если быть точным). Я стараюсь делать максимум для команды, а команда отвечает тем же. Если я вдруг прошу человека выйти за пределы нормы и сделать задачу к сроку, он мне не откажет. Правда, и прошу я таком совсем-совсем редко :)
Если хотите крутую команду, вам придется с ней дружить — в той или иной степени. Не в нашем обыденном понимании, а скорее в американском, когда friend'ом называют человека после пары месяцев общения.
Но это мое мнение. Что вы скажете: нравится вам руководитель-друг, пытаетесь ли вы стать друзьями с коллективом?
1️⃣ Первое, оно же главное — руководитель гораздо чаще хочет "стать друзьями" с подчиненными, чтобы насыпать им в панамку побольше работы. В ИТ реже, вне ИТ чаще бывает такое, что руководитель "лезет под кожу" подчиненным, пытается сойти за своего парня, чтобы получить больше возможности для манипуляций. Я пока еще ни одного руководителя не видел, которым подчиненные манипулировали.
2️⃣ Второе: если вы наняли людей, которые пользуются чужой добротой, вам надо учиться нанимать людей. Причем без разницы, эксплуатируют вашу доброту или чужую, таких нанимать не нужно, таких нужно увольнять. Вообще, нужно постараться, чтобы таких нанять.
3️⃣ Третье: реципрокность. Это очень, очень мощный механизм внутри каждого из нас, который на любую оказанную нам услугу требует у нас оказать услугу в ответ. Если механизм сломан, это сигнализирует об отклонениях, например — социопатии. Если руководитель оказывает услугу сотруднику, сотрудник окажет ее в ответ в 9 случаях из 10.
В общем, текст рекламы направлен на неуверенных в себе руководителях, которые почему-то хотят держать коллектив "шелковыми". Я б от такого ушел поскорее.
Моя история успеха — это как раз хороший коллектив друзей (friend'ов, если быть точным). Я стараюсь делать максимум для команды, а команда отвечает тем же. Если я вдруг прошу человека выйти за пределы нормы и сделать задачу к сроку, он мне не откажет. Правда, и прошу я таком совсем-совсем редко :)
Если хотите крутую команду, вам придется с ней дружить — в той или иной степени. Не в нашем обыденном понимании, а скорее в американском, когда friend'ом называют человека после пары месяцев общения.
Но это мое мнение. Что вы скажете: нравится вам руководитель-друг, пытаетесь ли вы стать друзьями с коллективом?
Философское.
У вас бывала мысль, что стоящий перед вами вызов может быть вам не по плечу? Что лучше не давить газ в пол и притормозить? Что задача слишком сложная, и вы не справитесь?
Если да, у меня для вас есть ответ. Точнее, не у меня, а у Фридриха Ницше.
Давайте расшифруем мысль философа по пунктам:
- Сложные вызовы — мерило вас как специалиста. Чем сложнее вызов, чем больше он вас пугает, тем лучше.
- Лишь самый сложный, самый страшный вызов заставит вас выложиться полностью и узнать свои возможности.
- Если вы избегаете сложных вызовов, вы никогда не узнаете, где же ваш предел.
- Единственный способ роста — постоянный поиск противника, который пугает вас, который заставляет вас усомниться в своих силах.
Я люблю фразу, что все мы дорастаем до уровня своей некомпетентности. Правда, далеко не все согласны дорасти; многие пасуют перед вызовами, и поэтому они никогда не узнают пределов своих возможностей.
Самое известное изречение из Хагакурэ: "Путь воина — это смерть" вторит идеям Ницше. Воин ищет противника, с которым ему уже не справиться, и в этом поиске становится собой.
Так что же делать, если перед вами стоит задача или направление, с которым вы боитесь не справиться?
Нужно пробовать. Это единственно верный ответ. Либо вы справитесь и станете лучшей версией себя, либо узнаете пределы своих возможностей. Ведь если вы завершите карьеру, так и не узнав своей максимум — разве это не будет разочарованием?
У вас бывала мысль, что стоящий перед вами вызов может быть вам не по плечу? Что лучше не давить газ в пол и притормозить? Что задача слишком сложная, и вы не справитесь?
Если да, у меня для вас есть ответ. Точнее, не у меня, а у Фридриха Ницше.
Сила нападающего имеет в противнике, который ему нужен, своего рода меру, всякое возрастание проявляется в искании более сильного противника — или проблемы: ибо философ, который воинствен, вызывает и проблемы на поединок. Задача не в том, чтобы победить вообще сопротивление, но преодолеть такое сопротивление, на которое нужно затратить всю свою силу, ловкость и умение владеть оружием, — равного противника…
Давайте расшифруем мысль философа по пунктам:
- Сложные вызовы — мерило вас как специалиста. Чем сложнее вызов, чем больше он вас пугает, тем лучше.
- Лишь самый сложный, самый страшный вызов заставит вас выложиться полностью и узнать свои возможности.
- Если вы избегаете сложных вызовов, вы никогда не узнаете, где же ваш предел.
- Единственный способ роста — постоянный поиск противника, который пугает вас, который заставляет вас усомниться в своих силах.
Я люблю фразу, что все мы дорастаем до уровня своей некомпетентности. Правда, далеко не все согласны дорасти; многие пасуют перед вызовами, и поэтому они никогда не узнают пределов своих возможностей.
Самое известное изречение из Хагакурэ: "Путь воина — это смерть" вторит идеям Ницше. Воин ищет противника, с которым ему уже не справиться, и в этом поиске становится собой.
Так что же делать, если перед вами стоит задача или направление, с которым вы боитесь не справиться?
Нужно пробовать. Это единственно верный ответ. Либо вы справитесь и станете лучшей версией себя, либо узнаете пределы своих возможностей. Ведь если вы завершите карьеру, так и не узнав своей максимум — разве это не будет разочарованием?
Двухфакторная теория мотивации Герцберга
Представьте себе две компании, обе хотят сделать своих сотрудников счастливее.
Первая компания сделала ставку только на высокий оклад и считает, что денег достаточно для удовлетворения людей.
Вторая мотивирует сотрудников только интересными задачами, обучением и вкладывается в развитие людей.
Вопрос: какая компания сделала правильный выбор?
Ответ: обе ошибаются.
Двухфакторная теория мотивации Герцберга выделает два направления, которые делают ваших сотрудников счастливыми.
- Удерживающие факторы: размер оклада, плюшки в офисе, крутой ДМС, вменяемый менеджмент.
- Мотивирующие факторы: интересные задачи, развитие, конференции, митапы и время на опенсорс.
Давайте разберемся, какие ситуации бывают:
- Забили и на удерживающие, и на мотивирующие факторы. Тут все просто: люди сбегут.
- Забили на удерживающие, вложились в мотивирующие. Вы вырастите отличные кадры, которые с удовольствием уведут ваши конкуренты на зарплату х2. Рынок скажет вам спасибо, но если что — так не делайте. Постоянные пригары из-за кривого менеджмента лишь ускорят процесс.
- Вложились в удерживающие, забили на мотивирующие. Тогда вы не сможете раскрыть ваших сотрудников полностью, ваш внутренний пул талантов останется неиспользованным. Литературно выражаясь, вы сидите на куче алмазов, которые могли бы превратить в бриллианты, но вам лень.
- Вложились и в то, и в это. Вы — молодец, а компания — мечта любого сотрудника.
Последующие исследования плюс-минус теорию Герцберга подтвердили, хотя и вызвали споры в научной среде. В следующих постах я расскажу про развитие мыслей Герцберга, так что пожалуйста, не воспринимайте написанное выше как истину, высеченную на скрижали. Используйте эти знания как еще один инструмент в вашей работе и помните: каждый инструмент имеет свою зону применения.
Представьте себе две компании, обе хотят сделать своих сотрудников счастливее.
Первая компания сделала ставку только на высокий оклад и считает, что денег достаточно для удовлетворения людей.
Вторая мотивирует сотрудников только интересными задачами, обучением и вкладывается в развитие людей.
Вопрос: какая компания сделала правильный выбор?
Ответ: обе ошибаются.
Двухфакторная теория мотивации Герцберга выделает два направления, которые делают ваших сотрудников счастливыми.
- Удерживающие факторы: размер оклада, плюшки в офисе, крутой ДМС, вменяемый менеджмент.
- Мотивирующие факторы: интересные задачи, развитие, конференции, митапы и время на опенсорс.
Давайте разберемся, какие ситуации бывают:
- Забили и на удерживающие, и на мотивирующие факторы. Тут все просто: люди сбегут.
- Забили на удерживающие, вложились в мотивирующие. Вы вырастите отличные кадры, которые с удовольствием уведут ваши конкуренты на зарплату х2. Рынок скажет вам спасибо, но если что — так не делайте. Постоянные пригары из-за кривого менеджмента лишь ускорят процесс.
- Вложились в удерживающие, забили на мотивирующие. Тогда вы не сможете раскрыть ваших сотрудников полностью, ваш внутренний пул талантов останется неиспользованным. Литературно выражаясь, вы сидите на куче алмазов, которые могли бы превратить в бриллианты, но вам лень.
- Вложились и в то, и в это. Вы — молодец, а компания — мечта любого сотрудника.
Последующие исследования плюс-минус теорию Герцберга подтвердили, хотя и вызвали споры в научной среде. В следующих постах я расскажу про развитие мыслей Герцберга, так что пожалуйста, не воспринимайте написанное выше как истину, высеченную на скрижали. Используйте эти знания как еще один инструмент в вашей работе и помните: каждый инструмент имеет свою зону применения.
Как понять на собеседовании, что чувак крутой и его надо брать?
Спросили меня недавно. Решил ответить в блоге: расскажу о каждом качестве соискателя в отдельном посте. Плюс подскажу, как можно рассмотреть наличие или отсутствие у человека конкретного качества.
Даже если вы никого не нанимаете, все равно полезно знать, чем лучше сверкнуть на собеседовании.
Но помните: идеального метода собеседования не существуют, ошибки найма будут всегда. Учитесь на них.
А первый признак крутого чувака это...
🧑🏼💻 Ему не пофигу на работу
Самое ценное качество в специалисте.
Это те люди, которые не закроют ноутбук, пока не пофиксят этот плавающий баг. Они будут повышать coverage тестов в чужом коде и следуют правилу "оставляй код чище, чем он был до тебя". Скорее всего, вам придется уговаривать их прекратить овертаймить, потому что оно того не стоит. Если нашли такого — удерживайте всеми силами и следите, чтобы не выгорел.
Даже если сотрудник не тащит по хардам, ничего страшного — хардам вы его научить сможете. А вот научить человека болеть душой за свое дело вы не сможете.
👀 Как увидеть на интервью
- Спросите, какие проблемы у него были на прошлом месте и как они решились. Именно решились — если кандидат рассказывает как его проблемы решали другие люди, это не тот случай. Если вы спросите "как решал", это зафреймит вопрос не в ту сторону. Наш кандидат решал свои проблемы самостоятельно и проактивно.
- Узнайте, влиял ли кандидат на бэклог команды. Проактивные чуваки сами наполняют бэклог найденным техдолгом.
⬇️ Обратная сторона
"Не пофигу" — не тумблер, который вы сможете выключить. Такие специалисты не смогут долго работать в компании, где их инициативы не видят, не ценят и не дают ход. Погрузите его в пучину легаси без возможности исправления — и вы его потеряете.
Если "не пофиг" у человека развито чрезмерно, он будет рьяно указывать людям на точки роста — их проекта и их личные. Некоторых будет триггерить такая назойливость. Если у вашей команды или отдела проблема, готовьтесь слышать на 1-1 критику в ваш адрес. Плохо ли это? Для меня — нет.
"Не пофигу" — самое ценное качество. Нанимайте таких людей, цените их и держитесь за них. Из них вырастут ваши будущие тимлиды, юнитлиды и — кто знает — ваша будущая замена, когда вы решите сменить работу.
Спросили меня недавно. Решил ответить в блоге: расскажу о каждом качестве соискателя в отдельном посте. Плюс подскажу, как можно рассмотреть наличие или отсутствие у человека конкретного качества.
Даже если вы никого не нанимаете, все равно полезно знать, чем лучше сверкнуть на собеседовании.
Но помните: идеального метода собеседования не существуют, ошибки найма будут всегда. Учитесь на них.
А первый признак крутого чувака это...
🧑🏼💻 Ему не пофигу на работу
Самое ценное качество в специалисте.
Это те люди, которые не закроют ноутбук, пока не пофиксят этот плавающий баг. Они будут повышать coverage тестов в чужом коде и следуют правилу "оставляй код чище, чем он был до тебя". Скорее всего, вам придется уговаривать их прекратить овертаймить, потому что оно того не стоит. Если нашли такого — удерживайте всеми силами и следите, чтобы не выгорел.
Даже если сотрудник не тащит по хардам, ничего страшного — хардам вы его научить сможете. А вот научить человека болеть душой за свое дело вы не сможете.
- Спросите, какие проблемы у него были на прошлом месте и как они решились. Именно решились — если кандидат рассказывает как его проблемы решали другие люди, это не тот случай. Если вы спросите "как решал", это зафреймит вопрос не в ту сторону. Наш кандидат решал свои проблемы самостоятельно и проактивно.
- Узнайте, влиял ли кандидат на бэклог команды. Проактивные чуваки сами наполняют бэклог найденным техдолгом.
"Не пофигу" — не тумблер, который вы сможете выключить. Такие специалисты не смогут долго работать в компании, где их инициативы не видят, не ценят и не дают ход. Погрузите его в пучину легаси без возможности исправления — и вы его потеряете.
Если "не пофиг" у человека развито чрезмерно, он будет рьяно указывать людям на точки роста — их проекта и их личные. Некоторых будет триггерить такая назойливость. Если у вашей команды или отдела проблема, готовьтесь слышать на 1-1 критику в ваш адрес. Плохо ли это? Для меня — нет.
"Не пофигу" — самое ценное качество. Нанимайте таких людей, цените их и держитесь за них. Из них вырастут ваши будущие тимлиды, юнитлиды и — кто знает — ваша будущая замена, когда вы решите сменить работу.
Please open Telegram to view this post
VIEW IN TELEGRAM
Самонаводимость
Второе качество, которое нужно смотреть. Впервые мне про него рассказал Миша Петров — СТО Рокетбанка. Когда я только начинал карьеру тимлида, я спросил у Миши, кто для него идеальный разработчик? Михаил ответил: "Идеальный разработчик — это самонаводящийся дятел, который получает задачу и летит долбить нужное дерево, пока не выдолбит". За точность цитаты не ручаюсь, но посыл такой.
❓ Что для меня значит самонаводимость
- Человек способен сам доуточнить задачу. Высокая самонаводимость позволяет человеку решать задачи с высокой неопределенностью. Например, если задача связана с бухгалтерией, он доуточнит у конкретного бухгалтера критерий готовности задачи. Конечно, в идеальном мире задача поставлена так, что доуточнять не придется — но где вы видели идеальный мир?
- Человек сам зайдет в другие команды, если нужна их помощь. Например, дойдет до девопс или фронтов и положит задачу к ним в бэклог без помощи своего тимлида.
- Когда человек "навелся", он не забьет на задачу, пока не получит результат. Я, например, помню много случаев, когда человек получал задачу, натыкался на какую-то трудность и забивал. Например, как-то раз программист поставил задачу соседней команде и забил. Когда его спросили, почему так, он ответил, что с его стороны пули вылетели. Классика! Самонаводящийся боец продолжал бы раз в день-два спрашивать, как поживает его задача.
👀 Как увидеть на интервью
- Спросите про задачи с самыми туманными требованиями и послушайте ответ. Не пугайтесь, если туманные требования соискателю не понравились — это не красный флаг, это нормально. Важно то, как он обработал эти туманные требования.
- Узнайте, как часто ему приходилось общаться к людьми не из своего отдела. В идеале, если это были люди даже не из ИТ, как можно ближе к бизнесу. Самонаводимые люди неизбежно контактируют с бизнесом.
- Задайте вопрос "расскажи мне про самую долгую задачу". Здесь важно узнать, насколько человек контролировал расплывшуюся по времени задачу и не забил ли он на нее.
⬇️ Обратная сторона
Чем выше самонаводимость, тем выше соблазн забить на формулировку задачи и просто говорить человеку "сделай хорошо, чо ты". Во-первых, это может демотивировать человека. Во-вторых, результат может в корне отличаться от того, что вы изначально ожидали.
Самонаводимость — отличное качество человека, которое в разы снижает время на его менеджмент и сильно выделяет человека из рядов обычных специалистов.
Второе качество, которое нужно смотреть. Впервые мне про него рассказал Миша Петров — СТО Рокетбанка. Когда я только начинал карьеру тимлида, я спросил у Миши, кто для него идеальный разработчик? Михаил ответил: "Идеальный разработчик — это самонаводящийся дятел, который получает задачу и летит долбить нужное дерево, пока не выдолбит". За точность цитаты не ручаюсь, но посыл такой.
- Человек способен сам доуточнить задачу. Высокая самонаводимость позволяет человеку решать задачи с высокой неопределенностью. Например, если задача связана с бухгалтерией, он доуточнит у конкретного бухгалтера критерий готовности задачи. Конечно, в идеальном мире задача поставлена так, что доуточнять не придется — но где вы видели идеальный мир?
- Человек сам зайдет в другие команды, если нужна их помощь. Например, дойдет до девопс или фронтов и положит задачу к ним в бэклог без помощи своего тимлида.
- Когда человек "навелся", он не забьет на задачу, пока не получит результат. Я, например, помню много случаев, когда человек получал задачу, натыкался на какую-то трудность и забивал. Например, как-то раз программист поставил задачу соседней команде и забил. Когда его спросили, почему так, он ответил, что с его стороны пули вылетели. Классика! Самонаводящийся боец продолжал бы раз в день-два спрашивать, как поживает его задача.
- Спросите про задачи с самыми туманными требованиями и послушайте ответ. Не пугайтесь, если туманные требования соискателю не понравились — это не красный флаг, это нормально. Важно то, как он обработал эти туманные требования.
- Узнайте, как часто ему приходилось общаться к людьми не из своего отдела. В идеале, если это были люди даже не из ИТ, как можно ближе к бизнесу. Самонаводимые люди неизбежно контактируют с бизнесом.
- Задайте вопрос "расскажи мне про самую долгую задачу". Здесь важно узнать, насколько человек контролировал расплывшуюся по времени задачу и не забил ли он на нее.
Чем выше самонаводимость, тем выше соблазн забить на формулировку задачи и просто говорить человеку "сделай хорошо, чо ты". Во-первых, это может демотивировать человека. Во-вторых, результат может в корне отличаться от того, что вы изначально ожидали.
Самонаводимость — отличное качество человека, которое в разы снижает время на его менеджмент и сильно выделяет человека из рядов обычных специалистов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Внутренний локус контроля
В психологии есть такая абстракция как локус контроля. У человек превалирует либо внешний, либо внутренний локус. В чем разница:
- Внешний локус контроля диктует человеку, что в его неудачах виноваты внешние факторы. Опоздал на работу — это проклятые пробки, ничего не могу поделать. Завалил спринт — это коллеги не вовремя завершили тестирование или развернули стенд, ничего не попишешь.
- Внутренний локус контроля диктует, что во всех неудачах виноваты мы сами. Если опоздали, то надо было раньше выходить из дома. Если спринт завалили, надо было активнее пинговать тестеров или девопсов.
К сожалению, мой опыт говорит, что локус контроля очень сложно сместить во внутрь, если у человека он находится вовне. Очень сложно — не значит невозможно.
❓ Почему внутренний локус — это хорошо?
Главный плюс человека с внутренним локусом — он не просто принимает внешние факторы, он старается их менять. Такая любимая всеми "проактивность" это следствие внутреннего локуса.
А еще с такими людьми просто приятнее общаться: сами подумайте, кому нравится, когда ваш собеседник винит в своих проблемах всех, кроме себя? Я заметил: чем более явно выражен у человека внешний локус, тем токсичнее его поведение.
❓ Как увидеть на интервью
Задать вопросы вида:
- "Расскажи про свой самый большой провал. Что привело тебя к нему?" — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но не делайте выводы лишь на основании одного ответа!
- Спросите про случаи, когда не удалось выстроить отношения с другой командой или человеком. Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.
⬇️ Обратная сторона
Люди с внутренним локусом любят загоняться там, где не надо. Иногда ситуация действительно диктует условия, с которыми можно только смириться. Но внутренний локус — это не отключаемая фича и за провалы такие люди съедают себя очень сурово.
Как считаете, какой локус превалирует у вас?
В психологии есть такая абстракция как локус контроля. У человек превалирует либо внешний, либо внутренний локус. В чем разница:
- Внешний локус контроля диктует человеку, что в его неудачах виноваты внешние факторы. Опоздал на работу — это проклятые пробки, ничего не могу поделать. Завалил спринт — это коллеги не вовремя завершили тестирование или развернули стенд, ничего не попишешь.
- Внутренний локус контроля диктует, что во всех неудачах виноваты мы сами. Если опоздали, то надо было раньше выходить из дома. Если спринт завалили, надо было активнее пинговать тестеров или девопсов.
К сожалению, мой опыт говорит, что локус контроля очень сложно сместить во внутрь, если у человека он находится вовне. Очень сложно — не значит невозможно.
Главный плюс человека с внутренним локусом — он не просто принимает внешние факторы, он старается их менять. Такая любимая всеми "проактивность" это следствие внутреннего локуса.
А еще с такими людьми просто приятнее общаться: сами подумайте, кому нравится, когда ваш собеседник винит в своих проблемах всех, кроме себя? Я заметил: чем более явно выражен у человека внешний локус, тем токсичнее его поведение.
Задать вопросы вида:
- "Расскажи про свой самый большой провал. Что привело тебя к нему?" — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но не делайте выводы лишь на основании одного ответа!
- Спросите про случаи, когда не удалось выстроить отношения с другой командой или человеком. Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.
Люди с внутренним локусом любят загоняться там, где не надо. Иногда ситуация действительно диктует условия, с которыми можно только смириться. Но внутренний локус — это не отключаемая фича и за провалы такие люди съедают себя очень сурово.
Как считаете, какой локус превалирует у вас?
Please open Telegram to view this post
VIEW IN TELEGRAM
Друзья, это заключительный пост в серии про интервью. Расскажите, помогли ли вам мои мысли и чего не хватило. Если понравилось, пожалуйста, поделитесь с друзьями — ваши репосты это главный двигатель канала и моя самая большая мотивация продолжать :)
Секреты small talk'а
Как познакомиться и завести разговор с незнакомым человеком, например, на конференции или корпоративе? Такие непринужденные разговоры называются small talk, у них нет конкретной задачи, просто знакомство с человеком.
И ведь small talk на самом деле — нифига не small. Это большая, важная часть постройки вашей карьеры, потому что полезные контакты забустят вас как ни что другое.
Проблема: мне бывает тяжело просто заговорить с кем-то. А если заговорил, то непонятно, о чем вести беседу. А если провел, то неудобно завершить разговор, чтобы собеседника не задеть.
Мэтт Абрамс ответил на все эти вопросы в видосе, а вам я принес краткую выжимку.
Советы Мэтта
- Начните разговор необычно. Это самая сложная часть, ведь не все могут подойти и спросить "привет, как дела". Свяжите начало разговора с окружающей ситуацией. Если это стенд компании на конференции, спросите, понравился ли он собеседнику. В очереди за кофе после доклада можно спросить про сам доклад. Фантазия и наблюдательность — ваши лучшие друзья.
- Не пытайтесь быть интересным, будьте заинтересованным. Не думайте, что вам нужно быть зажигательным и искрометным, одного лишь интереса к вашему собеседнику будет достаточно. Люди любят, когда их слушают и спрашивают.
- Не бойтесь паузы в разговоре. Когда в разговоре подвисает пауза, мы стремимся как можно быстрее ее заполнить вообще чем угодно и может сморозить что-то странное. Верный способ продолжить разговор — перефразировать последние слова вашего собеседника. Это еще и даст понять собеседнику, что вы его слушаете и понимаете — а люди любят, когда их слушают и понимают!
- Если вам нечего сказать — спросите вопрос. Бывает, что с сути сказанного вам нечего добавить, и тогда лучший способ продолжить беседу это спросить "можете рассказать мне еще?" или попросить дать больше деталей.
- Если вы сказали что-то глупое, это ок. Сморозить странность в разговоре — норма, мы все ошибаемся. Думайте про ошибку как про неудачный дубль в фильме, который не испортит конечный результат, а даже сделает его интереснее.
- Не говорите слишком много. Условно, если у вас спросили время, лучше ответить "пол-второго", а не рассказывать устройство часов. Говорите выводами, если вам не попросили об обратном.
- Придерживайтесь структуры. Мэтт советует такую: расскажите "про что-то", потом почему это "что-то" важно для собеседника и затем — что собеседник может сделать с вашей информацией. Например, вы рассказали про свою оптимизацию БД. Продолжите рассказом про то, насколько выросла производительность приложения. Потом спросите, актуальна ли проблема для вашего собеседника и как он ее решил бы или уже решил.
- Не завершайте разговор резко. Я обычно говорил "сори, мне еще нужно сделать что-то" и уходил. Это — ошибка! Лучше скажите "мне уже пора, но перед тем как я пойду, скажи пожалуйста..." и дальше задайте один последний вопрос про тему вашей беседы. Так вы завершите разговор максимально корректно и оставите впечатление внимательного и заинтересованного человека.
На этом все! Поделитесь вашими лайфхаками для small talk'ов? Нам всем интересно :)
Как познакомиться и завести разговор с незнакомым человеком, например, на конференции или корпоративе? Такие непринужденные разговоры называются small talk, у них нет конкретной задачи, просто знакомство с человеком.
И ведь small talk на самом деле — нифига не small. Это большая, важная часть постройки вашей карьеры, потому что полезные контакты забустят вас как ни что другое.
Проблема: мне бывает тяжело просто заговорить с кем-то. А если заговорил, то непонятно, о чем вести беседу. А если провел, то неудобно завершить разговор, чтобы собеседника не задеть.
Мэтт Абрамс ответил на все эти вопросы в видосе, а вам я принес краткую выжимку.
Советы Мэтта
- Начните разговор необычно. Это самая сложная часть, ведь не все могут подойти и спросить "привет, как дела". Свяжите начало разговора с окружающей ситуацией. Если это стенд компании на конференции, спросите, понравился ли он собеседнику. В очереди за кофе после доклада можно спросить про сам доклад. Фантазия и наблюдательность — ваши лучшие друзья.
- Не пытайтесь быть интересным, будьте заинтересованным. Не думайте, что вам нужно быть зажигательным и искрометным, одного лишь интереса к вашему собеседнику будет достаточно. Люди любят, когда их слушают и спрашивают.
- Не бойтесь паузы в разговоре. Когда в разговоре подвисает пауза, мы стремимся как можно быстрее ее заполнить вообще чем угодно и может сморозить что-то странное. Верный способ продолжить разговор — перефразировать последние слова вашего собеседника. Это еще и даст понять собеседнику, что вы его слушаете и понимаете — а люди любят, когда их слушают и понимают!
- Если вам нечего сказать — спросите вопрос. Бывает, что с сути сказанного вам нечего добавить, и тогда лучший способ продолжить беседу это спросить "можете рассказать мне еще?" или попросить дать больше деталей.
- Если вы сказали что-то глупое, это ок. Сморозить странность в разговоре — норма, мы все ошибаемся. Думайте про ошибку как про неудачный дубль в фильме, который не испортит конечный результат, а даже сделает его интереснее.
- Не говорите слишком много. Условно, если у вас спросили время, лучше ответить "пол-второго", а не рассказывать устройство часов. Говорите выводами, если вам не попросили об обратном.
- Придерживайтесь структуры. Мэтт советует такую: расскажите "про что-то", потом почему это "что-то" важно для собеседника и затем — что собеседник может сделать с вашей информацией. Например, вы рассказали про свою оптимизацию БД. Продолжите рассказом про то, насколько выросла производительность приложения. Потом спросите, актуальна ли проблема для вашего собеседника и как он ее решил бы или уже решил.
- Не завершайте разговор резко. Я обычно говорил "сори, мне еще нужно сделать что-то" и уходил. Это — ошибка! Лучше скажите "мне уже пора, но перед тем как я пойду, скажи пожалуйста..." и дальше задайте один последний вопрос про тему вашей беседы. Так вы завершите разговор максимально корректно и оставите впечатление внимательного и заинтересованного человека.
На этом все! Поделитесь вашими лайфхаками для small talk'ов? Нам всем интересно :)
Мыши предсказывают вероятности лучше людей
Разум — наш самый главный инструмент, но порой он становится нашей главной слабостью. Например, самые обычные мыши могут справиться с задачей на вероятность лучше людей. Не верите? Читайте дальше :)
Эксперимент
Для исследования ученые взяли мышей и дали им на выбор две кнопки: зеленую и красную. После нажатия на одну из кнопок, следовала пауза, после которой одна из кнопок подсвечивалась. Зеленая светилась в 80% случаев, красная — в 20%. Если мышь угадывала, какая кнопка загорится, и нажимала на нее, ей давали кусочек сыра. Если не угадывала, ее били током.
Мыши достаточно быстро принимали правила игры и просто постоянно нажимали на зеленую кнопку. Таким образом, процент угадывания мышей стремился к 80%.
После мышей, такой же эксперимент провели на людях. Людям озвучили, что зеленая кнопка загорается в 80% случаев. Но испытуемые человеки постоянно пытались угадать, какая кнопка загорится следующей, и это дало средний процент успеха в 68%.
Несмотря на заранее озвученную вероятность, человеческий мозг продолжил искать шаблоны в вероятности и это значительно ухудшило результат. Мы вообще плохо дружим с вероятностями, что в своих книгах описывает и Канеман, и Талеб. Человек пытается переиграть случайность и проигрывает — этим, кстати, пользуются всякие казино.
Вывод
Люди любят искать шаблоны и корреляцию даже там, где их нет — в чистой случайности. Лабораторные мыши справились с задачей значительно лучше, просто потому что не пытались играть с вероятностями и выбрали более действенную стратегию. Еще раз: мыши выбрали более правильную стратегию, чем люди!
Примеры из жизни
В реальности мы тоже любим играть с вероятностями и проигрывать. Например:
- Вероятность того, что наши сроки по проекту слишком оптимистичны — высока, но мы в них верим и коммитимся.
- Вероятность инцидента релиза в вечер пятницы высока, но мы релизим и проводим выходные в увлекательном квесте "поймай плавающий баг"
Что делать?
Я описывал в своем посте "игру победителя" и что не всегда стоит пытаться переиграть события. Порой лучше поверить в вероятность и выбрать стратегию, которая по-настоящему минимизирует риски.
Разум — наш самый главный инструмент, но порой он становится нашей главной слабостью. Например, самые обычные мыши могут справиться с задачей на вероятность лучше людей. Не верите? Читайте дальше :)
Эксперимент
Для исследования ученые взяли мышей и дали им на выбор две кнопки: зеленую и красную. После нажатия на одну из кнопок, следовала пауза, после которой одна из кнопок подсвечивалась. Зеленая светилась в 80% случаев, красная — в 20%. Если мышь угадывала, какая кнопка загорится, и нажимала на нее, ей давали кусочек сыра. Если не угадывала, ее били током.
Мыши достаточно быстро принимали правила игры и просто постоянно нажимали на зеленую кнопку. Таким образом, процент угадывания мышей стремился к 80%.
После мышей, такой же эксперимент провели на людях. Людям озвучили, что зеленая кнопка загорается в 80% случаев. Но испытуемые человеки постоянно пытались угадать, какая кнопка загорится следующей, и это дало средний процент успеха в 68%.
Несмотря на заранее озвученную вероятность, человеческий мозг продолжил искать шаблоны в вероятности и это значительно ухудшило результат. Мы вообще плохо дружим с вероятностями, что в своих книгах описывает и Канеман, и Талеб. Человек пытается переиграть случайность и проигрывает — этим, кстати, пользуются всякие казино.
Вывод
Люди любят искать шаблоны и корреляцию даже там, где их нет — в чистой случайности. Лабораторные мыши справились с задачей значительно лучше, просто потому что не пытались играть с вероятностями и выбрали более действенную стратегию. Еще раз: мыши выбрали более правильную стратегию, чем люди!
Примеры из жизни
В реальности мы тоже любим играть с вероятностями и проигрывать. Например:
- Вероятность того, что наши сроки по проекту слишком оптимистичны — высока, но мы в них верим и коммитимся.
- Вероятность инцидента релиза в вечер пятницы высока, но мы релизим и проводим выходные в увлекательном квесте "поймай плавающий баг"
Что делать?
Я описывал в своем посте "игру победителя" и что не всегда стоит пытаться переиграть события. Порой лучше поверить в вероятность и выбрать стратегию, которая по-настоящему минимизирует риски.
Менеджеры не нужны!
Именно так подумал Ларри Пейдж, СЕО Google в 2001-ом году и кикнул всех менеджеров их компании. Пейджа не устраивала скорость разработки. Мотивация у Пейджа была такая:
- Гугл нанимает лучших инженеров, у которых все ок с мотивацией
- Лучшие инженеры сами могут решать, что им делать и как держать дедлайны
- Менеджеры гораздо слабее в технике, чем инженеры, и поэтому не могут руководить инженерами
- Менеджеры отвлекают инженеров от задач своими глупыми активностями
Сказано — сделано, и в компании Google не остается ни одного менеджера. Все 130 инженеров компании теперь репортят одному вице-президенту, Вейну Розингу. Менеджеры, кстати, офигели — никто их заранее не предупредил. Их просто собрали вместе и сообщили новость, что они больше не нужны.
Прекрасная жизнь без менеджмента
Когда инженеров оставили без менеджеров, произошло вот что:
- Проекты остались без ресурсов. Некому было распределить ресурсы разработки в те проекты, где они больше всего требовались. Вейн Розинг банально не мог менеджерить все проекты и ресурсы для них.
- Работа дублировалась. Два разных инженера могли решать одну и ту же задачу одновременно, даже не зная друг о друге. В итоге, одно из решений просто выкидывали в помойку.
- Инженеры демотивировались. Некому было дать обратную связь за проделанную работу, некому было подсказать дальнейший вектор развития в карьере.
- Задачи не делались. Инженеры любят интересную работу, а неинтересную работы мы не любим и предпочитаем делать ее когда-нибудь потом. Без участия менеджмента, инженеры брались только за те задачи, которые хотели. Скучные, но нужные задачи, просто пылились в самом низу бэклога.
- Конфликты нарастали. Спор двух сеньоров — страшное дело, особенно если рядом нет никого, кто мог бы решить их разногласия. Без внешнего участия, такой конфликт иногда кончается тотальным отказом работать друг с другом.
Итог
Сроки по задачам выросли, некоторые задачи простаивали вечность, а инженеры теряли мотивацию работать. Не все — некоторые люди действительно лучше работали без менеджеров, но их оказалось слишком мало.
Менеджеров пришлось нанимать обратно спустя некоторое время. Эксперимент признали неудачным и вернули все как было.
Именно так подумал Ларри Пейдж, СЕО Google в 2001-ом году и кикнул всех менеджеров их компании. Пейджа не устраивала скорость разработки. Мотивация у Пейджа была такая:
- Гугл нанимает лучших инженеров, у которых все ок с мотивацией
- Лучшие инженеры сами могут решать, что им делать и как держать дедлайны
- Менеджеры гораздо слабее в технике, чем инженеры, и поэтому не могут руководить инженерами
- Менеджеры отвлекают инженеров от задач своими глупыми активностями
Сказано — сделано, и в компании Google не остается ни одного менеджера. Все 130 инженеров компании теперь репортят одному вице-президенту, Вейну Розингу. Менеджеры, кстати, офигели — никто их заранее не предупредил. Их просто собрали вместе и сообщили новость, что они больше не нужны.
Прекрасная жизнь без менеджмента
Когда инженеров оставили без менеджеров, произошло вот что:
- Проекты остались без ресурсов. Некому было распределить ресурсы разработки в те проекты, где они больше всего требовались. Вейн Розинг банально не мог менеджерить все проекты и ресурсы для них.
- Работа дублировалась. Два разных инженера могли решать одну и ту же задачу одновременно, даже не зная друг о друге. В итоге, одно из решений просто выкидывали в помойку.
- Инженеры демотивировались. Некому было дать обратную связь за проделанную работу, некому было подсказать дальнейший вектор развития в карьере.
- Задачи не делались. Инженеры любят интересную работу, а неинтересную работы мы не любим и предпочитаем делать ее когда-нибудь потом. Без участия менеджмента, инженеры брались только за те задачи, которые хотели. Скучные, но нужные задачи, просто пылились в самом низу бэклога.
- Конфликты нарастали. Спор двух сеньоров — страшное дело, особенно если рядом нет никого, кто мог бы решить их разногласия. Без внешнего участия, такой конфликт иногда кончается тотальным отказом работать друг с другом.
Итог
Сроки по задачам выросли, некоторые задачи простаивали вечность, а инженеры теряли мотивацию работать. Не все — некоторые люди действительно лучше работали без менеджеров, но их оказалось слишком мало.
Менеджеров пришлось нанимать обратно спустя некоторое время. Эксперимент признали неудачным и вернули все как было.
"Если я изобрел стори поинты, я извиняюсь за это"
Написал создатель стори поинтов Рон Джеффрис у себя в блоге. Рон изначально изобрел модель "идеального дня" — это реальный день, когда тебя не отвлекают на созвоны и параллельные задачи. Задачи оценивались в идеальных днях, умноженных на коэффициент три, чтобы учесть время на созвоны и прерывания в работе. Позже идеальные дни Рон переименовал в стори поинты, и началось.
Ниже я кратко привожу аргументы Рона. Не могу сказать, что согласен с ним полностью. Не принимайте это как истину в последней инстанции, это — лишь мнение человека. Пусть и создателя поинтов.
Сравнить команды
Разные команды могут оценить одну и ту же задачу по-разному. Это не означает, что одна команда слабее другой. Стори поинты родились из концепции "идеального дня" — без созвонов и прерываний.
Сравнивать команды на основе их оценок в стори поинтах нельзя, потому что:
- У разных команд отличается количество созвонов и прерываний
- Команды работают с разным количеством технического долга и легаси
Для сравнения команд стори поинты не подходят.
Сравнить сроки
Если вы оценили задачу в стори поинтах, нужно в итоге сравнить реальные сроки выполнения и изначальную оценку, ведь так? Если оценка и реальность разошлись, нужно провести ретроспективу, понять причины и начать оценивать лучше?
Нет. Суть айджайла — делать самые приоритетные задачи как можно быстрее. Стори поинты не помогут вам приоритизировать задачи. Стори поинты не помогут вам ускорить реализацию и доставку ценности — для этого вам нужно учиться разбивать большую задачу на маленькие, но ценные инкременты.
Так что стори поинты и тут бесполезны.
Давить на команду
В красной книге SCRUM сказано, что количество стори поинтов, которые команда берет в спринт, должно постоянно расти от спринта к спринту. Такой подход приведет к майндсету "количество важнее, чем качество" — разработка начнет срезать углы и копить технический долг, а QA начнут пропускать баги.
Это как постоянно сжимать пружину в погоне за количеством. Рано или поздно, пружина разожмется и, может быть, попадет кому-то в лоб.
Если вы разбили большие куски работы на небольшие задачи и поставляете ценность регулярно, этого достаточно.
Стори поинты хороши для давления на команду, но само давление — плохая идея.
Предсказать сроки
Если задача большая (на квартал), вы не сможете сказать, когда вы ее сделаете. Вы можете потратить время на устранение неизвестности и даже немного преуспеть, но точных сроков у вас не получится.
Вместо попытки предсказать неизвестное, лучше поставить максимум ценности к заданному сроку. Для этого стори поинты не нужны.
Вывод
Вот ссылка на статью. Честно — я пока не могу подписаться под всем сказанным выше. Попробую расписать в следующих постах каждый пункт. Очень хочу послушать ваше мнение насчет написаного, жду в комментарии. Не стесняйтесь, давайте думать вместе :)
Написал создатель стори поинтов Рон Джеффрис у себя в блоге. Рон изначально изобрел модель "идеального дня" — это реальный день, когда тебя не отвлекают на созвоны и параллельные задачи. Задачи оценивались в идеальных днях, умноженных на коэффициент три, чтобы учесть время на созвоны и прерывания в работе. Позже идеальные дни Рон переименовал в стори поинты, и началось.
Ниже я кратко привожу аргументы Рона. Не могу сказать, что согласен с ним полностью. Не принимайте это как истину в последней инстанции, это — лишь мнение человека. Пусть и создателя поинтов.
Сравнить команды
Разные команды могут оценить одну и ту же задачу по-разному. Это не означает, что одна команда слабее другой. Стори поинты родились из концепции "идеального дня" — без созвонов и прерываний.
Сравнивать команды на основе их оценок в стори поинтах нельзя, потому что:
- У разных команд отличается количество созвонов и прерываний
- Команды работают с разным количеством технического долга и легаси
Для сравнения команд стори поинты не подходят.
Сравнить сроки
Если вы оценили задачу в стори поинтах, нужно в итоге сравнить реальные сроки выполнения и изначальную оценку, ведь так? Если оценка и реальность разошлись, нужно провести ретроспективу, понять причины и начать оценивать лучше?
Нет. Суть айджайла — делать самые приоритетные задачи как можно быстрее. Стори поинты не помогут вам приоритизировать задачи. Стори поинты не помогут вам ускорить реализацию и доставку ценности — для этого вам нужно учиться разбивать большую задачу на маленькие, но ценные инкременты.
Так что стори поинты и тут бесполезны.
Давить на команду
В красной книге SCRUM сказано, что количество стори поинтов, которые команда берет в спринт, должно постоянно расти от спринта к спринту. Такой подход приведет к майндсету "количество важнее, чем качество" — разработка начнет срезать углы и копить технический долг, а QA начнут пропускать баги.
Это как постоянно сжимать пружину в погоне за количеством. Рано или поздно, пружина разожмется и, может быть, попадет кому-то в лоб.
Если вы разбили большие куски работы на небольшие задачи и поставляете ценность регулярно, этого достаточно.
Стори поинты хороши для давления на команду, но само давление — плохая идея.
Предсказать сроки
Если задача большая (на квартал), вы не сможете сказать, когда вы ее сделаете. Вы можете потратить время на устранение неизвестности и даже немного преуспеть, но точных сроков у вас не получится.
Вместо попытки предсказать неизвестное, лучше поставить максимум ценности к заданному сроку. Для этого стори поинты не нужны.
Вывод
Вот ссылка на статью. Честно — я пока не могу подписаться под всем сказанным выше. Попробую расписать в следующих постах каждый пункт. Очень хочу послушать ваше мнение насчет написаного, жду в комментарии. Не стесняйтесь, давайте думать вместе :)