Использование грейдов: частые ошибки
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
План по приведению отдела в порядок, разбираем предновогодний кейс
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов