Неймдроппинг
Давайте сыграем в игру. Допустим, вы хотите убедить разработчика сделать задачу, которая не в его бэклоге. Практика плохая, но иногда приходится. Я могу привести плюс-минус три категории аргументов, чтобы это сделать:
- A — Задача поможет заработать нам денег
- B — Задача интересная и поможет тебе прокачаться
- C — Задачу поставил сам Иван Иванович, понимать надо!
Какой бы выбрали вы? Для меня лучший аргумент — заработок компании, но для подавляющего большинства людей интерес к задаче важнее. Поэтому я бы выбрал В и давил на него. Однако, выбрать А не будет ошибкой.
Ошибкой будет выбрать С. Это я называю неймдроппинг: использование чьего-то имени в качестве единственного аргумента для выполнении или повышения приоритета задачи. Это красный флаг и зачастую гарантия того, что менеджер свою работу делать не умеет.
Если же применять неймдроппинг в числе прочих аргументов, иногда это не так плохо, но я все же советую избегать.
Почему неймдроппинг — плохо
- Вы прячетесь от ответственности за свои поступки и необходимости отстаивать свою позицию. Это очень слабая позиция, которая мешает менеджеру расти. Когда менеджер-неймдроппер получает в ответ "кто такой Иван Иваныч?", он становится беспомощен.
- Вы буквально сами взращиваете в себе синдром самозванца. Сами подумайте: если вы постоянно прикрываетесь кем-то и его мнением, чего стоит ваше собственное мнение?
- Вы раздражаете окружающих. Никто не любит неймдроппинг, правда.
Альтернативы неймдроппингу
Помимо мотивации пользой (приоритетами) и ростом, есть еще варианты:
- Замена — если вам так надо впихнуть в бэклог новую задачу, сделайте это, но уберите одну старую примерно того же объема работы.
- Бартер — предложите команде, в которую вы хотите пропихнуть работу, свою помощь. Выделите им своего QA, помогите ревьюить MR'ы, включитесь вместо них в дежурства.
- Примером — попросите у команды список текущих и предстоящих крупных задач. Потом сравните каждую из них со своей задаче и коротко опишите, почему ваша важнее.
Давайте сыграем в игру. Допустим, вы хотите убедить разработчика сделать задачу, которая не в его бэклоге. Практика плохая, но иногда приходится. Я могу привести плюс-минус три категории аргументов, чтобы это сделать:
- A — Задача поможет заработать нам денег
- B — Задача интересная и поможет тебе прокачаться
- C — Задачу поставил сам Иван Иванович, понимать надо!
Какой бы выбрали вы? Для меня лучший аргумент — заработок компании, но для подавляющего большинства людей интерес к задаче важнее. Поэтому я бы выбрал В и давил на него. Однако, выбрать А не будет ошибкой.
Ошибкой будет выбрать С. Это я называю неймдроппинг: использование чьего-то имени в качестве единственного аргумента для выполнении или повышения приоритета задачи. Это красный флаг и зачастую гарантия того, что менеджер свою работу делать не умеет.
Если же применять неймдроппинг в числе прочих аргументов, иногда это не так плохо, но я все же советую избегать.
Почему неймдроппинг — плохо
- Вы прячетесь от ответственности за свои поступки и необходимости отстаивать свою позицию. Это очень слабая позиция, которая мешает менеджеру расти. Когда менеджер-неймдроппер получает в ответ "кто такой Иван Иваныч?", он становится беспомощен.
- Вы буквально сами взращиваете в себе синдром самозванца. Сами подумайте: если вы постоянно прикрываетесь кем-то и его мнением, чего стоит ваше собственное мнение?
- Вы раздражаете окружающих. Никто не любит неймдроппинг, правда.
Альтернативы неймдроппингу
Помимо мотивации пользой (приоритетами) и ростом, есть еще варианты:
- Замена — если вам так надо впихнуть в бэклог новую задачу, сделайте это, но уберите одну старую примерно того же объема работы.
- Бартер — предложите команде, в которую вы хотите пропихнуть работу, свою помощь. Выделите им своего QA, помогите ревьюить MR'ы, включитесь вместо них в дежурства.
- Примером — попросите у команды список текущих и предстоящих крупных задач. Потом сравните каждую из них со своей задаче и коротко опишите, почему ваша важнее.
Будущее непредсказуемо
В 80-ых годах компания AT&T крепко задумалась: заходить ли им в рынок изготовления мобильных телефонов. AT&T занимались телекомом, так что смежное направление мобильных телефонов выглядело перспективным, но рискованным. Компания переживала, что сотовые телефоны — это просто игрушка для богатых людей, а не стабильный рынок.
Чтобы помочь самим себе сделать выбор, AT&T пригласили компанию McKinsey составить прогноз: сколько сотовых телефонов будет на руках у жителей США в 2000-м году?
Для справки: McKinsey это очень-очень крутая консалтинговая компания, топ оф зе топ, сrème de la сrème. Клиенты McKinsey это Google и Microsoft, так что парни там сидят очень серьезные.
И эти серьезные парни должны быть дать серьезный прогноз. В конце-концов, это их работа, а они — профессионалы. Ведь так?
Не совсем
McKinsey посчитали, что к 2000-му году у жителей США будет на руках около 900 тыс. мобильных телефонов. AT&T решила не заходить на рынок мобильных телефонов (позже они изменят решение, но время будет потеряно).
Как думаете, насколько ошиблись McKinsey? Ваши ставки? В три раза? В десять раз?
Более, чем в сто раз. В 2000-м году по разным оценкам у жителей США на руках находилось более 100 млн. мобильных телефонов. А AT&T упустила миллиарды (триллионы?) долларов.
Вывод
Каждый раз, когда я читаю про попытку предсказать будущее касаемо нейросетей, искусственного интеллекта, электромобилей и вообще чего угодно, я вспоминаю этот случай.
Нельзя предсказать будущее. Можно предположить и сделать ставку на определенный исход, но предсказать — нельзя.
В 80-ых годах компания AT&T крепко задумалась: заходить ли им в рынок изготовления мобильных телефонов. AT&T занимались телекомом, так что смежное направление мобильных телефонов выглядело перспективным, но рискованным. Компания переживала, что сотовые телефоны — это просто игрушка для богатых людей, а не стабильный рынок.
Чтобы помочь самим себе сделать выбор, AT&T пригласили компанию McKinsey составить прогноз: сколько сотовых телефонов будет на руках у жителей США в 2000-м году?
Для справки: McKinsey это очень-очень крутая консалтинговая компания, топ оф зе топ, сrème de la сrème. Клиенты McKinsey это Google и Microsoft, так что парни там сидят очень серьезные.
И эти серьезные парни должны быть дать серьезный прогноз. В конце-концов, это их работа, а они — профессионалы. Ведь так?
Не совсем
McKinsey посчитали, что к 2000-му году у жителей США будет на руках около 900 тыс. мобильных телефонов. AT&T решила не заходить на рынок мобильных телефонов (позже они изменят решение, но время будет потеряно).
Как думаете, насколько ошиблись McKinsey? Ваши ставки? В три раза? В десять раз?
Более, чем в сто раз. В 2000-м году по разным оценкам у жителей США на руках находилось более 100 млн. мобильных телефонов. А AT&T упустила миллиарды (триллионы?) долларов.
Вывод
Каждый раз, когда я читаю про попытку предсказать будущее касаемо нейросетей, искусственного интеллекта, электромобилей и вообще чего угодно, я вспоминаю этот случай.
Нельзя предсказать будущее. Можно предположить и сделать ставку на определенный исход, но предсказать — нельзя.
Наткнулся на правила общения в компании 37signals
Понравились, перевел для вас самые интересные:
2. Предпочитайте асинхронное общение — чатики или почту, но иногда можно и синхронное — звонки или встречи.
5. Встречи или созвоны — решение на крайний случай, а не выбор по умолчанию.
8. Если ваши слова могут понять неоднозначно, большинство людей поймет их максимально вредным и оскорбительным образом.
9. Никогда не ожидайте немедленного ответа ни от кого. Если только у вас не случился пожар, конечно. Требования немедленного ответа — это токсичное поведение.
11. Плохая коммуникация создает больше работы.
13. Пять людей на часовой встрече — это не один, а пять потраченных часов.
15. Коммуникация не должна требовать синхронизации. Календари тоже не связаны с коммуникацией. Письменную речь можно отвязать и от синхронизации, и от календаря.
16. "Сейчас" редко является лучшим временем для высказывания мысли, которая только что родилась у вас в голове. Дайте ей настояться. То, что останется через время — и есть та часть, которую стоить говорить.
19. Чтобы узнать ответ, надо задать вопрос. Чтобы получить правильный ответ, надо задать правильный вопрос. У людей вообще есть что вам рассказать, но редко есть желание подходить без спросу.
21. Срочность переоценена, ASAP — яд.
22. Если вы пытаетесь донести сложную новость, пригласите людей задавать вопросы в конце вашего письма или речи. Сложная весть без возможности ее обсудить — лучшая почва для слухов и сплетен.
25. Не перемешивайте плохие и хорошие новости, подавайте их отдельно.
26. Время на твоей стороне, а вот спешка лишь усложнит коммуникацию.
27. Общайтесь напрямую с теми, с кем вам нужно общаться. Избегайте передачи мыслей через кого-то.
29. Если нужная и важная коммуникация случится в неподходящее время, считайте, что никакой коммуникации и не было.
И еще бонус. Почему они не включили это как правило — не знаю, по-моему, лучшая идея:
> We don’t use email internally
Очень захотелось затащить к нам такое.
Понравились, перевел для вас самые интересные:
2. Предпочитайте асинхронное общение — чатики или почту, но иногда можно и синхронное — звонки или встречи.
5. Встречи или созвоны — решение на крайний случай, а не выбор по умолчанию.
8. Если ваши слова могут понять неоднозначно, большинство людей поймет их максимально вредным и оскорбительным образом.
9. Никогда не ожидайте немедленного ответа ни от кого. Если только у вас не случился пожар, конечно. Требования немедленного ответа — это токсичное поведение.
11. Плохая коммуникация создает больше работы.
13. Пять людей на часовой встрече — это не один, а пять потраченных часов.
15. Коммуникация не должна требовать синхронизации. Календари тоже не связаны с коммуникацией. Письменную речь можно отвязать и от синхронизации, и от календаря.
16. "Сейчас" редко является лучшим временем для высказывания мысли, которая только что родилась у вас в голове. Дайте ей настояться. То, что останется через время — и есть та часть, которую стоить говорить.
19. Чтобы узнать ответ, надо задать вопрос. Чтобы получить правильный ответ, надо задать правильный вопрос. У людей вообще есть что вам рассказать, но редко есть желание подходить без спросу.
21. Срочность переоценена, ASAP — яд.
22. Если вы пытаетесь донести сложную новость, пригласите людей задавать вопросы в конце вашего письма или речи. Сложная весть без возможности ее обсудить — лучшая почва для слухов и сплетен.
25. Не перемешивайте плохие и хорошие новости, подавайте их отдельно.
26. Время на твоей стороне, а вот спешка лишь усложнит коммуникацию.
27. Общайтесь напрямую с теми, с кем вам нужно общаться. Избегайте передачи мыслей через кого-то.
29. Если нужная и важная коммуникация случится в неподходящее время, считайте, что никакой коммуникации и не было.
И еще бонус. Почему они не включили это как правило — не знаю, по-моему, лучшая идея:
> We don’t use email internally
Очень захотелось затащить к нам такое.
Le Saboteur
В 1944 ЦРУ выпустила книгу "Простой саботаж", чтобы помочь европейскому сопротивлению в их борьбе: вредить, но при этом не слишком вызывающе, тайно. И вы сейчас очень сильно удивитесь, потому что кажется, что некоторые нынешние руководители взяли ее за мануал :) Смотрите сами:
Вот несколько оригинальных советов
- Настаивайте на использовании каналов связи, не позволяйте людям из разных отделов общаться друг с другом ради решения проблемы — только через процессы!
- Толкайте речи: тягучие, развесистые, полные деталей из вашей жизни, историй и пары анекдотов.
- Создавайте комитеты для любых задач, для каких только возможно — минимум из пяти человек!
Далее попробуем переложить их на наши реалии
СТО
- Первым делом потребуйте полгода-год, чтобы переписать все легаси.
- Сделайте так, чтобы для локальной разработки надо было поднять 10-12 сервисов разом.
- Убедитесь, что для каждой буковки в коде создана задача, история или даже эпик.
- Настаивайте, что любое техническое решение должно выдержать нагрузку минимум в х10 от текущей.
- Наймите как можно больше архитекторов, устройте архитектурный комитет и проводите сквозь него любую мало-мальски большую фичу.
Менеджеры
- Ставьте мит для решения любой — любой! — проблемы.
- Сделайте так, чтобы один человек репортил как можно большему количеству людей: тимлиду, лидеру гильдии, лидеру функции и кому-нибудь еще.
- Почаще переводите андер-перформящих людей в другие команды.
Проджект менеджеры
- Пытайтесь включить в проект как можно больше разных команд. Бонус-поинт, если они будут из разных часовых поясов :)
- Требуйте точной оценки в часах всех задач. Всех!
Готово! Вы великолепный саботер, Франция может вами гордиться :) Если интересно подробнее и больше, вот оригинал.
В 1944 ЦРУ выпустила книгу "Простой саботаж", чтобы помочь европейскому сопротивлению в их борьбе: вредить, но при этом не слишком вызывающе, тайно. И вы сейчас очень сильно удивитесь, потому что кажется, что некоторые нынешние руководители взяли ее за мануал :) Смотрите сами:
Вот несколько оригинальных советов
- Настаивайте на использовании каналов связи, не позволяйте людям из разных отделов общаться друг с другом ради решения проблемы — только через процессы!
- Толкайте речи: тягучие, развесистые, полные деталей из вашей жизни, историй и пары анекдотов.
- Создавайте комитеты для любых задач, для каких только возможно — минимум из пяти человек!
Далее попробуем переложить их на наши реалии
СТО
- Первым делом потребуйте полгода-год, чтобы переписать все легаси.
- Сделайте так, чтобы для локальной разработки надо было поднять 10-12 сервисов разом.
- Убедитесь, что для каждой буковки в коде создана задача, история или даже эпик.
- Настаивайте, что любое техническое решение должно выдержать нагрузку минимум в х10 от текущей.
- Наймите как можно больше архитекторов, устройте архитектурный комитет и проводите сквозь него любую мало-мальски большую фичу.
Менеджеры
- Ставьте мит для решения любой — любой! — проблемы.
- Сделайте так, чтобы один человек репортил как можно большему количеству людей: тимлиду, лидеру гильдии, лидеру функции и кому-нибудь еще.
- Почаще переводите андер-перформящих людей в другие команды.
Проджект менеджеры
- Пытайтесь включить в проект как можно больше разных команд. Бонус-поинт, если они будут из разных часовых поясов :)
- Требуйте точной оценки в часах всех задач. Всех!
Готово! Вы великолепный саботер, Франция может вами гордиться :) Если интересно подробнее и больше, вот оригинал.
Здравствуйте, это ваша сила воли
Да, прямо на картинке. Эта часть мозга называется Anterior cingulate cortex, или Передняя поясная кора (ППК), и ее можно накачать, почти как мышцы.
С чего это я взял
В ходе исследований (пример) ученые установили прямую связь между размером ППК и "силой воли" человека — способностью делать то, что не хочется и не делать то, что хочется. Если все так, что формула простая: чем больше ППК, тем "больше" у вас силы воли.
Экспериментов было много, два примера:
- Людей сажали решать сложные задачи и измеряли мозговую активность.
- С помощью электродов стимулировали ППК напрямую. Люди описывали свои ощущения так: "как будто бы надвигается гроза, но я хочу вбежать прямо в нее".
Причины роста ППК
Наш мозг может изменяться даже во взрослом возрасте. ППК — одна из областей мозга, где нейрогенез возможен даже во взрослом возрасте, так что выводы из исследований будут полезны всем.
Чтобы увеличиться ППК, надо ее использовать: чем больше мы используем ППК, тем больше в размере она становится. Например, ППК больше у людей, которые:
- Занимаются спортом
- Медитируют
С другой стороны, ППК будет меньше у людей:
- С избыточным весом
- С низкой активностью
- И так далее
Что с этим всем делать лично вам
Очень важно запомнить формулу:
- Чем чаще вы используете силу воли, тем легче вам в следующий раз использовать ее.
- Чем реже вы используете силу воли, тем сложнее вам ей пользоваться в следующие разы.
Если вы поддаетесь желанию съесть лишний кексик, в следующий раз сопротивляться будет сложнее. Если кексик вы все-таки не съели, в следующий раз отказаться станет еще проще.
Но помните: наука может ошибаться, и все это опровергнут через сто лет. Или нет :)
Да, прямо на картинке. Эта часть мозга называется Anterior cingulate cortex, или Передняя поясная кора (ППК), и ее можно накачать, почти как мышцы.
С чего это я взял
В ходе исследований (пример) ученые установили прямую связь между размером ППК и "силой воли" человека — способностью делать то, что не хочется и не делать то, что хочется. Если все так, что формула простая: чем больше ППК, тем "больше" у вас силы воли.
Экспериментов было много, два примера:
- Людей сажали решать сложные задачи и измеряли мозговую активность.
- С помощью электродов стимулировали ППК напрямую. Люди описывали свои ощущения так: "как будто бы надвигается гроза, но я хочу вбежать прямо в нее".
Причины роста ППК
Наш мозг может изменяться даже во взрослом возрасте. ППК — одна из областей мозга, где нейрогенез возможен даже во взрослом возрасте, так что выводы из исследований будут полезны всем.
Чтобы увеличиться ППК, надо ее использовать: чем больше мы используем ППК, тем больше в размере она становится. Например, ППК больше у людей, которые:
- Занимаются спортом
- Медитируют
С другой стороны, ППК будет меньше у людей:
- С избыточным весом
- С низкой активностью
- И так далее
Что с этим всем делать лично вам
Очень важно запомнить формулу:
- Чем чаще вы используете силу воли, тем легче вам в следующий раз использовать ее.
- Чем реже вы используете силу воли, тем сложнее вам ей пользоваться в следующие разы.
Если вы поддаетесь желанию съесть лишний кексик, в следующий раз сопротивляться будет сложнее. Если кексик вы все-таки не съели, в следующий раз отказаться станет еще проще.
Но помните: наука может ошибаться, и все это опровергнут через сто лет. Или нет :)
Закон Брукса
Нельзя тушить пожар бензином. С этим любой согласен. Однако, если проект начинает гореть, менеджер начинает заливать его людьми.
Закон Брукса так и говорит: каждый новый человек в уже горящий по срокам проект приведет к дальнейшему росту сроков. Так что заливать горящий проект людьми это все равно что тушить пожар бензином, не очень хорошая идея. Но почему так?
Почему закон Брукса работает
- Новые люди должны влиться в команду. Вил Ларсон в "Элегантном Пазле" называет это геллингом. Чтобы выйти на уровень эффективности, новый разработчик должен со всеми перезнакомиться, запомнить, как запускать всякие магические скрипты, к какому девопсу ходить, а к какому не надо, к кому идти за советом касаемо то или иной части кода — ну короче, геллинг. Что еще хуже: существующая команда тоже потратит время, чтобы влить к себе новичка.
- Новые люди повышают налог на коммуникацию. Я приложил к посту картинку, насколько быстро растет число горизонтальных (и только горизонтальных!) коммуникаций с ростом команды.
- Некоторые задачи нельзя распараллелить. Как девять женщин не родят ребенка за месяц, так и некоторую задачу просто нельзя ускорить людьми. Как правило, это какой-нибудь ресерч или технически сложная задача.
Что же теперь делать
Если ваш проект горит, я знаю три надежных варианта действий, чтобы успеть:
- Перенести сроки на подальше.
- Порезать скоуп задач, чтобы бэклог стал поменьше.
- Использовать принцип "бах-бах и в продакшн", то есть набрать кучу техдолга.
Если знаете еще варианты, пишите в комментарии :)
Нельзя тушить пожар бензином. С этим любой согласен. Однако, если проект начинает гореть, менеджер начинает заливать его людьми.
Закон Брукса так и говорит: каждый новый человек в уже горящий по срокам проект приведет к дальнейшему росту сроков. Так что заливать горящий проект людьми это все равно что тушить пожар бензином, не очень хорошая идея. Но почему так?
Почему закон Брукса работает
- Новые люди должны влиться в команду. Вил Ларсон в "Элегантном Пазле" называет это геллингом. Чтобы выйти на уровень эффективности, новый разработчик должен со всеми перезнакомиться, запомнить, как запускать всякие магические скрипты, к какому девопсу ходить, а к какому не надо, к кому идти за советом касаемо то или иной части кода — ну короче, геллинг. Что еще хуже: существующая команда тоже потратит время, чтобы влить к себе новичка.
- Новые люди повышают налог на коммуникацию. Я приложил к посту картинку, насколько быстро растет число горизонтальных (и только горизонтальных!) коммуникаций с ростом команды.
- Некоторые задачи нельзя распараллелить. Как девять женщин не родят ребенка за месяц, так и некоторую задачу просто нельзя ускорить людьми. Как правило, это какой-нибудь ресерч или технически сложная задача.
Что же теперь делать
Если ваш проект горит, я знаю три надежных варианта действий, чтобы успеть:
- Перенести сроки на подальше.
- Порезать скоуп задач, чтобы бэклог стал поменьше.
- Использовать принцип "бах-бах и в продакшн", то есть набрать кучу техдолга.
Если знаете еще варианты, пишите в комментарии :)
Когда найм — это решение
Прямо сейчас в одной из моих команд происходит 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