#рецепт
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!
Давай немного поговорим о вот какой теме - как вести себя менеджеру, чтобы что-то поменять в рабочих процессах. Ты наверняка задашься вопросом "А зачем как-то себя вести по особенному? Берешь и делаешь, я же менеджер, полномочия мне дали."
Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;
Во-вторых: многие работают в крупных организациях, где процессы спущены сверху и вот так просто их не поменяешь.
Так как же вести себя менеджеру, чтобы устранить проблему в процессах? Я бы даже предложил так:
1) Выявить процесс.
Не просто менять что-то абстрактное что не нравится, а конкретно сформулировать что будет объектом усилий и его границы "от сих до сих". Четко сформулировать что идет на вход, а что на выход.
Поздравляю, теперь ты знаешь хотя бы с чем будешь иметь дело и это поможет в пункте 2;
2) Понять потребности.
Буквально. Нужно узнать кого затрагивает процесс из пункта 1 и кто на него может влиять (стейкхолдеров в общем). Вот у них узнаем а каковы их потребности в случае процесса 1. Должно получиться что-то вроде ("Васе нужна оценка задач для личного комфорта, чтобы была определенность");
3) Подтвердить проблему.
Почти наверняка проблему тут видишь только ты. Если ты посмотришь на информацию из пункта 2, то возможно окажется что до этого мало кому есть дело и тебя не поддержат при решении проблемы, потому что ее не видят. Поэтому задайся вопросом "для кого это проблема, а для кого нет?" Также будет полезно непрямыми вопросами уточнить это у стейкхолдеров.
Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.
Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".
Главное завалидировать с с участниками процесса — есть ли проблема и видят ли они через новое представление.
4) Получить добро на решение проблемы.
Даже если ты показал участникам проблему, они могут просто не признать что ее надо решать и решать именно тебе. Поэтому нужно сперва показать что вы получите от решения проблемы - "вижен лучшей жизни" или бенефиты (если решим проблему А, то станет лучше Б вот на столько). Ну и конечно получи явное добро либо от большинства группы, либо от самого влиятельного.
5) Применить менеджерские инструменты
Это может быть что угодно, от 5 шагов теории ограничений систем и до системного мышления и канбан-метода, тут скорее зависит от того в чем вы разобрались и понимание границ применимости. А еще лучше никому не говорите что конкретно вы применяете, чтобы не столкнутся с предубеждением относительно инструмента, с помощью которого вы чините, такой вот партизанский менеджмент.
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!
Давай немного поговорим о вот какой теме - как вести себя менеджеру, чтобы что-то поменять в рабочих процессах. Ты наверняка задашься вопросом "А зачем как-то себя вести по особенному? Берешь и делаешь, я же менеджер, полномочия мне дали."
Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;
Во-вторых: многие работают в крупных организациях, где процессы спущены сверху и вот так просто их не поменяешь.
Так как же вести себя менеджеру, чтобы устранить проблему в процессах? Я бы даже предложил так:
1) Выявить процесс.
Не просто менять что-то абстрактное что не нравится, а конкретно сформулировать что будет объектом усилий и его границы "от сих до сих". Четко сформулировать что идет на вход, а что на выход.
Поздравляю, теперь ты знаешь хотя бы с чем будешь иметь дело и это поможет в пункте 2;
2) Понять потребности.
Буквально. Нужно узнать кого затрагивает процесс из пункта 1 и кто на него может влиять (стейкхолдеров в общем). Вот у них узнаем а каковы их потребности в случае процесса 1. Должно получиться что-то вроде ("Васе нужна оценка задач для личного комфорта, чтобы была определенность");
3) Подтвердить проблему.
Почти наверняка проблему тут видишь только ты. Если ты посмотришь на информацию из пункта 2, то возможно окажется что до этого мало кому есть дело и тебя не поддержат при решении проблемы, потому что ее не видят. Поэтому задайся вопросом "для кого это проблема, а для кого нет?" Также будет полезно непрямыми вопросами уточнить это у стейкхолдеров.
Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.
Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".
Главное завалидировать с с участниками процесса — есть ли проблема и видят ли они через новое представление.
4) Получить добро на решение проблемы.
Даже если ты показал участникам проблему, они могут просто не признать что ее надо решать и решать именно тебе. Поэтому нужно сперва показать что вы получите от решения проблемы - "вижен лучшей жизни" или бенефиты (если решим проблему А, то станет лучше Б вот на столько). Ну и конечно получи явное добро либо от большинства группы, либо от самого влиятельного.
5) Применить менеджерские инструменты
Это может быть что угодно, от 5 шагов теории ограничений систем и до системного мышления и канбан-метода, тут скорее зависит от того в чем вы разобрались и понимание границ применимости. А еще лучше никому не говорите что конкретно вы применяете, чтобы не столкнутся с предубеждением относительно инструмента, с помощью которого вы чините, такой вот партизанский менеджмент.
#рецепт
Продолжение поста про изменение процессов
6) Готовьтесь огрести
Даже если вы нарисуете схему всего процесса, даже если вы визуализируете процесс, даже если вы получите право и власть быть арбитром процесса и вы запустите петлю обратной связи о прохождении запросов по всему жизненному циклу процесса - у вас может не получиться.
Люди могут:
- саботировать процесс
- строить потемкинские деревни
- впадать в итальянскую забастовку и т.д.
Это все будет выглядеть так, что вы как "самый умный в комнате" предлагаете им универсальное решение, а это может задевать их эго, идентичность и самоощущение. Поэтому я бы предложил рассмотреть для исследования вопрос - "почему люди сейчас поступают так как поступают?". Вы можете найти очень много интересных вещей, которым надо будет адресовать ваши усилия. Просто для примера:
- люди могут быть перегружены
- люди могут быть в состоянии анемии (если я правильно использовал этот термин... состоянии когда: "я не знаю как действовать в такой ситуации")
- люди могут иметь мотивацию поступать так, как поступают и эта мотиваця вызвана определенными фаторами, например лоальный KPI
и т.п.
P.S. Многое что есть группах людей (особенно в энтерпрайз компаниях) происходит вопреки, казалось бы, здравому смыслу. Все потому что есть люди и с ними сложно. Главная сила менеджера состоит в умении превращать оковы из людей в возможности
P.P.S. Часть 6 не моя, она от @pimenas Леши Пименова
Продолжение поста про изменение процессов
6) Готовьтесь огрести
Даже если вы нарисуете схему всего процесса, даже если вы визуализируете процесс, даже если вы получите право и власть быть арбитром процесса и вы запустите петлю обратной связи о прохождении запросов по всему жизненному циклу процесса - у вас может не получиться.
Люди могут:
- саботировать процесс
- строить потемкинские деревни
- впадать в итальянскую забастовку и т.д.
Это все будет выглядеть так, что вы как "самый умный в комнате" предлагаете им универсальное решение, а это может задевать их эго, идентичность и самоощущение. Поэтому я бы предложил рассмотреть для исследования вопрос - "почему люди сейчас поступают так как поступают?". Вы можете найти очень много интересных вещей, которым надо будет адресовать ваши усилия. Просто для примера:
- люди могут быть перегружены
- люди могут быть в состоянии анемии (если я правильно использовал этот термин... состоянии когда: "я не знаю как действовать в такой ситуации")
- люди могут иметь мотивацию поступать так, как поступают и эта мотиваця вызвана определенными фаторами, например лоальный KPI
и т.п.
P.S. Многое что есть группах людей (особенно в энтерпрайз компаниях) происходит вопреки, казалось бы, здравому смыслу. Все потому что есть люди и с ними сложно. Главная сила менеджера состоит в умении превращать оковы из людей в возможности
P.P.S. Часть 6 не моя, она от @pimenas Леши Пименова
#рецепт
Не путаем показатели
Небольшая шпаргалка по показателям, которые очень часто проскальзывают в речи менеджеров по делу и без. Надеюсь после прочтения будет только по делу)
Прогнозируемость = вероятность ошибки прогнозирования.
Эффективность = затраты / результат
Результативность = фактический результат / плановый результат
Точность = абсолютная величина ошибки планирования или погрешность.
План-факт = плановый результат - фактический результат
Производительность = количество результата в единицу времени.
Стабильность = величина отклонения от среднего.
Как только ты перестанешь путать это, можно топать в более тонкие материи вроде Fill Rate, Capacity/Velocity, Lead time, Time to Market, Tact time, Service Level (без A и E) и прочее прочее.
Не путаем показатели
Небольшая шпаргалка по показателям, которые очень часто проскальзывают в речи менеджеров по делу и без. Надеюсь после прочтения будет только по делу)
Прогнозируемость = вероятность ошибки прогнозирования.
Эффективность = затраты / результат
Результативность = фактический результат / плановый результат
Точность = абсолютная величина ошибки планирования или погрешность.
План-факт = плановый результат - фактический результат
Производительность = количество результата в единицу времени.
Стабильность = величина отклонения от среднего.
Как только ты перестанешь путать это, можно топать в более тонкие материи вроде Fill Rate, Capacity/Velocity, Lead time, Time to Market, Tact time, Service Level (без A и E) и прочее прочее.
#полезности
Словарь джуна
Коллеги создали табличку с мудреными словами. Авось кому будет полезно.
Основная задача #словарь_джуна - снизить стресс и облегчить адаптацию молодого специалиста, пришедшего после университета или переходящего в ИТ сферу из другой профессии. Как показала практика и отзывы студентов, именно повседневно используемые ИТ-специалистами сленг и жаргонизмы, не описанные ни в одном учебнике, вызывают наибольшие сложности в первые недели работы молодого специалиста.
https://docs.google.com/spreadsheets/d/1X1uYlGl9KA5GayIoYOwVKB-1XoBFkA97FqWXSkw73n8/edit?usp=sharing
P.S. Не мое, Автор @egormaryushko
Словарь джуна
Коллеги создали табличку с мудреными словами. Авось кому будет полезно.
Основная задача #словарь_джуна - снизить стресс и облегчить адаптацию молодого специалиста, пришедшего после университета или переходящего в ИТ сферу из другой профессии. Как показала практика и отзывы студентов, именно повседневно используемые ИТ-специалистами сленг и жаргонизмы, не описанные ни в одном учебнике, вызывают наибольшие сложности в первые недели работы молодого специалиста.
https://docs.google.com/spreadsheets/d/1X1uYlGl9KA5GayIoYOwVKB-1XoBFkA97FqWXSkw73n8/edit?usp=sharing
P.S. Не мое, Автор @egormaryushko
Google Docs
Словарь джуна
👍3
#рецепт
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.
Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".
Если решать вопрос буквально, то обычно есть обучающий курс, страница новичка или регламент для менеджера/тимлида о том как надо онбордить. И формально ты действительно узнаешь доступы, какие фичи есть в проекте, на каких технология он делается, где лежит документация, культуру поведения в компании и тд. Но я очень сомневаюсь что это даст то самое понимание с большой буквы лично для тебя, глубинное.
Я пришел к следующему рецепту из 5 шагов:
1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.
Давай подробно разберем каждый из них.
Дневник людей
Ты вел когда-нибудь дневник себя самого? Вот тоже самое, но только про вон тех ребят. По каждому коллеге пиши заметки. Сегодня Василий Петрович был бодрячком, делай проброску в топик кафки поля по задаче. Нужно записывать не так много:
- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).
Ценность этой информации не в том что она документирована и по ней можно предъявлять или манипулировать людьми (не надо так делать). По этим записям ты научишься чувствовать людей и сможешь раскрыться как руководитель на новом месте гораздо быстрее. Процесс наблюдений выработает привычку быть внимательным к коллегам и понимать их, процесс записи научит структурировать образ о человеке, а процесс просмотра этих записей потом позволит заметить негативные или позитивные тенденции.
Сделать работу каждого руками
Под каждым имей в виду каждого стейкхолдера. Хочешь понять разработчиков и особенности их работы? Попросись сделать что-то простое сам, с помощью чего ты сможешь понять почему у ребят так долго идет ревью или бомбежку от IDE. Ну и конечно ты станешь к ним ближе, потому что их проблемы буквально станут твоими проблемами и ты их переживешь.
И не надо говорить что ты не разработчик/аналитик/девопс. Полно простых вещей, в которых можно разобраться за день и выполнить работу. Не боги горшки обжигают.
Нужно взять по задаче у каждого из членов команды, но еще лучше напроситься к бизнесовым стейкхолдерам (в продуктовой/внутренней разработке это возможно). Если что-то из этого можно сделать в режиме "парного программирования", то вообще шикарно.
Дневник изменений
Записывай то что происходило точки зрения процессов. Сегодня у нас 10% отставание от графика, заказчик ругался, пред-прод упал. Записывай именно факты и особенно те, у которых есть численное выражение. В дальнейшем это позволит тебе увидеть зависимости между явлениями.
Пример - ретро было введено месяц назад, за счет решения проблем уменьшили техдолг и скорость выкатки релизов сократилась в 2 раза. Это уже косвенное подтверждение правильно принятых решений.
Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.
Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".
Если решать вопрос буквально, то обычно есть обучающий курс, страница новичка или регламент для менеджера/тимлида о том как надо онбордить. И формально ты действительно узнаешь доступы, какие фичи есть в проекте, на каких технология он делается, где лежит документация, культуру поведения в компании и тд. Но я очень сомневаюсь что это даст то самое понимание с большой буквы лично для тебя, глубинное.
Я пришел к следующему рецепту из 5 шагов:
1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.
Давай подробно разберем каждый из них.
Дневник людей
Ты вел когда-нибудь дневник себя самого? Вот тоже самое, но только про вон тех ребят. По каждому коллеге пиши заметки. Сегодня Василий Петрович был бодрячком, делай проброску в топик кафки поля по задаче. Нужно записывать не так много:
- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).
Ценность этой информации не в том что она документирована и по ней можно предъявлять или манипулировать людьми (не надо так делать). По этим записям ты научишься чувствовать людей и сможешь раскрыться как руководитель на новом месте гораздо быстрее. Процесс наблюдений выработает привычку быть внимательным к коллегам и понимать их, процесс записи научит структурировать образ о человеке, а процесс просмотра этих записей потом позволит заметить негативные или позитивные тенденции.
Сделать работу каждого руками
Под каждым имей в виду каждого стейкхолдера. Хочешь понять разработчиков и особенности их работы? Попросись сделать что-то простое сам, с помощью чего ты сможешь понять почему у ребят так долго идет ревью или бомбежку от IDE. Ну и конечно ты станешь к ним ближе, потому что их проблемы буквально станут твоими проблемами и ты их переживешь.
И не надо говорить что ты не разработчик/аналитик/девопс. Полно простых вещей, в которых можно разобраться за день и выполнить работу. Не боги горшки обжигают.
Нужно взять по задаче у каждого из членов команды, но еще лучше напроситься к бизнесовым стейкхолдерам (в продуктовой/внутренней разработке это возможно). Если что-то из этого можно сделать в режиме "парного программирования", то вообще шикарно.
Дневник изменений
Записывай то что происходило точки зрения процессов. Сегодня у нас 10% отставание от графика, заказчик ругался, пред-прод упал. Записывай именно факты и особенно те, у которых есть численное выражение. В дальнейшем это позволит тебе увидеть зависимости между явлениями.
Пример - ретро было введено месяц назад, за счет решения проблем уменьшили техдолг и скорость выкатки релизов сократилась в 2 раза. Это уже косвенное подтверждение правильно принятых решений.
Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п
#рецепт
Как включаться в работу на новом месте. Часть 2
Личный проект по онбордингу
Классический проект. С треугольником, только вместо бюджета 1 ресурс - ты сам.
Обязательные артефакты:
1. Устав. Бизнес-кейс, цели, критерии достижения целей, детерминирующие риски, допущения, поставки, ограничения. Такой устав кстати выступает хорошим "контрактом" на испытательный срок, так как описывает что нужно сделать чтобы его пройти с отличием;
2. Матрица требований. Описание того, что конкретно нужно сделать за испытательный срок или онбординг;
3. Реестр рисков. Что может помешать пройти всему как по маслу? Очень даже может быть злющий тимлид, который попросит на выход если ты ему не понравишься и откажется сотрудничать;
4. Матрица коммуникаций. В каждой компании есть набор встреч, созвонов и тд. Знать как они проходят и когда очень важно;
5. Календарный план. Нужно спланировать свое время, чтобы успеть все сделать и не перегрузится.
Кстати если завести матрицу требований как чеклист того, что нужно сделать для достижения цели проекта, то это станет хорошим подспорьем для 1-1 с руководителем и инкрементального продвижению к успеху.
Регламент работы менеджера
Не-не, это не для того чтобы покрыть все свою работу (задницу) бумагами. А именно для того чтобы понять что и как надо делать. Тебе нужно по долгу службы писать ТЗ? Окей, напиши для себя как здесь пишут ТЗ. Сам процесс записи медиативный и позволяет раскладывать информацию по полочкам.
От таких заметок есть и еще несколько польз.:
1. Всегда можно подсмотреть как делается что-то;
2. Если нужно уйти в отпуск/заболеть, то так проще передавать дела.
P.S Это мой личный ТОП-5 действий, которые нужно сделать чтобы включиться в работу на новом месте. Не все из них при смене рабочего места я делал сразу, о чем в последствии жалею.
P.S.S Нет пункта "сходить в бар с коллегами", потому что это маст-хев и по умолчанию.
Как включаться в работу на новом месте. Часть 2
Личный проект по онбордингу
Классический проект. С треугольником, только вместо бюджета 1 ресурс - ты сам.
Обязательные артефакты:
1. Устав. Бизнес-кейс, цели, критерии достижения целей, детерминирующие риски, допущения, поставки, ограничения. Такой устав кстати выступает хорошим "контрактом" на испытательный срок, так как описывает что нужно сделать чтобы его пройти с отличием;
2. Матрица требований. Описание того, что конкретно нужно сделать за испытательный срок или онбординг;
3. Реестр рисков. Что может помешать пройти всему как по маслу? Очень даже может быть злющий тимлид, который попросит на выход если ты ему не понравишься и откажется сотрудничать;
4. Матрица коммуникаций. В каждой компании есть набор встреч, созвонов и тд. Знать как они проходят и когда очень важно;
5. Календарный план. Нужно спланировать свое время, чтобы успеть все сделать и не перегрузится.
Кстати если завести матрицу требований как чеклист того, что нужно сделать для достижения цели проекта, то это станет хорошим подспорьем для 1-1 с руководителем и инкрементального продвижению к успеху.
Регламент работы менеджера
Не-не, это не для того чтобы покрыть все свою работу (задницу) бумагами. А именно для того чтобы понять что и как надо делать. Тебе нужно по долгу службы писать ТЗ? Окей, напиши для себя как здесь пишут ТЗ. Сам процесс записи медиативный и позволяет раскладывать информацию по полочкам.
От таких заметок есть и еще несколько польз.:
1. Всегда можно подсмотреть как делается что-то;
2. Если нужно уйти в отпуск/заболеть, то так проще передавать дела.
P.S Это мой личный ТОП-5 действий, которые нужно сделать чтобы включиться в работу на новом месте. Не все из них при смене рабочего места я делал сразу, о чем в последствии жалею.
P.S.S Нет пункта "сходить в бар с коллегами", потому что это маст-хев и по умолчанию.
#мнение
Story Points. Изобретение дьявола. Часть 1
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
Миф 1. СП это из Scrum
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
Миф 2. СП это относительные оценки
Тут происходит путаница из-за того что СП часто отождествляют с методом покер-планированием. Покер-планирование это метод, который придумал Джеймс Греннинг на основе метода Дельфи , а популяризировал его все тот же Майкл Кон. Это метод экспертной оценки, но не задач, а вообще оценки любых показателей и призван для нивелирования влияния мнения лидера (если тимлид сказал что надо 5 дней на задачу, то попробуй ему возрази) и для шаринга знаний о сущности работы.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Миф 3. СП это оценка сложности.
Само себе определение СП путает. СП - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
- Объем работы (как много времени потребуется чтобы сделать работу);
- Сложность работы (величина умственной нагрузки);
- Неопределенность (риски и неуверенность что это можно сделать).
Миф 4. Можно переводить СП в часы
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
- Логический. Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды;
- Математический. Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться;
- Смысловой. Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Если все таки очень хочется конвертировать. Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".
Что забавно, изначально СП предполагались как идеальные дни, которые конвертировались в обычные умножение на коэффиент нагрузки, равный примерно 3
Story Points. Изобретение дьявола. Часть 1
Привет, искушенный читатель! Если ты вращаешься вокруг проектного управления и Agile, то наверняка слышал о таком понятии как сторипойнты. Для краткости их буду указывать по тексту как СП.
Я обозвал их изобретением дьявола потому что они обладают специфическими свойствами, которые легко вводят в заблуждение неокрепшие умы. В этой статье я бы хотел немного рассказать про них и развеять несколько мифов.
Миф 1. СП это из Scrum
СП придумал Рон Джеффрис году эдак в 2001 (точных дат нет), затем их популяризировал Майкл Кон в своей книге Agile: оценка и планирование проектов.
Что забавно, изначально в 1 версии гайда (в 2010 году) предполагалось планирование в идеальных человеко-днях.
Миф 2. СП это относительные оценки
Тут происходит путаница из-за того что СП часто отождествляют с методом покер-планированием. Покер-планирование это метод, который придумал Джеймс Греннинг на основе метода Дельфи , а популяризировал его все тот же Майкл Кон. Это метод экспертной оценки, но не задач, а вообще оценки любых показателей и призван для нивелирования влияния мнения лидера (если тимлид сказал что надо 5 дней на задачу, то попробуй ему возрази) и для шаринга знаний о сущности работы.
В покер-пленнинге использует относительный подход, когда собравшимися выбирается единица отсчета, относительно которой оценивают другие рассматриваемые объекты.
Сами по себе СП не являются относительными изначально.
Миф 3. СП это оценка сложности.
Само себе определение СП путает. СП - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы.
Казалось бы в чем разница между усилиями и трудозатратами?
Но если разбираться чуть дальше, то окажется что СП состоит из 3 измерений, которые нужно держать в голове при оценке:
- Объем работы (как много времени потребуется чтобы сделать работу);
- Сложность работы (величина умственной нагрузки);
- Неопределенность (риски и неуверенность что это можно сделать).
Миф 4. Можно переводить СП в часы
Очень известный миф, каждый второй ПМ и СМ путаются так делать. Тут есть 3 момента, которые этому помешают:
- Логический. Если сторипойнты оценки усилий команды для реализации определенного скоупа, то часы это рабочее время, которая затратит команда на реализацию скоупа. Почему-то строится такое выражение: усилия == рабочее время команды;
- Математический. Есть два различных показателя. Мы не знаем есть ли между ними связь (например, линейная корреляция), поэтому переводить показатели из одного базиса в другой каким-то выдуманным коэффицентом бессмысленно. Даже если связь есть, то нужно найти формулу перевода, а она может не выражаться алгоритмически, просто нет аппроксимирующей кривой или что еще забавнее временные ряды этих показателей могут не сходиться;
- Смысловой. Был оценен хвост кота, насколько он пушистый и крепкий. А теперь давайте по хвосту найдем сколько еды ест в неделю такой кот. Перевод теплое в мягкое.
Если все таки очень хочется конвертировать. Выбери примерно 100 задач с оценкой в СП, посчитай сколько на каждую задачу ушло времени (не оцени, а именно посчитай, cycle time от старта работы и до конца). Затем посчитай линейный коэффициент Пирсона между оценкой и временем. Если он больше 0.5, построй кривую по оценке и попробуйте ее аппроксимировать другой кривой по методу наименьших квадратов. Это самый простой способ "в лоб".
Что забавно, изначально СП предполагались как идеальные дни, которые конвертировались в обычные умножение на коэффиент нагрузки, равный примерно 3
👍1
#мнение
Story Points. Изобретение дьявола. Часть 2
Миф 5. Емкость команды в СП выражает ее эффективность и можно по ней сравнивать команды
Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному. Даже если стандартизировать их способ мышления при оценке и способ выполнения работы, то ничего не получится. СП применяют для нематериального производство, которое происходит в разумах людей. И как в поговорке "к сожалению к рукам сотрудника прилагается и остальной человек".
Не нужно оценивать эффективность по количеству СП и тем более сравнивать 2 команды. ты сравниваешь одни уникальные усилия с другими уникальными усилиями. Оценивайте результат.
Миф 6. Сначала оценим СП аналитика, потом разработчика, потом тестировщика
При оценке СП участвуют все члены команды, каждый высказывают свою оценку сразу целиком по всей задаче. Даже аналитик, хотя он не разработчик и не знает как это точно закодить.
Работает такая оценка на опыте и СП предполагает именно усилия команды, а не отдельных ее членов.
Рассматривать команду надо не как группу индивидуумов, временно собранных вместе волею судеб, а как нечто неделимое, чёрный ящик, куда можно забросить задание и получить результат.
Что забавно, СП почти никогда не работает в группах людей, которые не понимают смысла работы друг друга и не работают на единой целью.
Миф 7. При декомпозиции задачи также декомпозируется ее оценка в СП
Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.
Ну и плюс немного дополнительных умозаключений:
1. Нарезать истории на подзадачи никому кроме команды и не надо. Они сами себе её нарежут так, как им удобно. Декомпозиция нужна именно для увеличения знаний о задаче и удобства работы с ней. Не для оценки;
2. Оценивать подзадачи тоже не надо, никому не интересно, сколько будет делаться конкретная подзадача, всем интересен конечный результат - готовая задача.
Миф 8. СП можно складывать
Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.
Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет)
Также появляется интересный вывод - капасити это не сумма СП, а просто их количество.
Миф 9. СП лучше часов. Штуки задач лучше СП. NoEstimates!!!
СП необходимы для оценки усилий и дальнейшего выбора в контейнер времени наиболее важных задач (часто такой контейнер называют спринтом).
Часы нужны для прогнозирования того, сколько денег будет потрачено. Все сроки, дедлайны сводятся к одному - когда будет произведен возврат инвестиций, а это именно про деньги.
А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.
Единственное преимущество, которые дают штуки задач относительно СП - это то что можно просто не тратить время на оценку. В остальном их точность прогнозирования, например с помощью Монте-Карло примерно одинаковая.
Миф 10. СП подходят для долгосрочного планирования
Из предыдущего мифа следует простой вывод. СП нужны только на коротком промежутке времени и применяются именно для решения "сколько работы уложится в итерацию". После запуска итерации смысл СП исчезает.
Так как оценка СП выражает объем, риски и сложность, то оценивать весь беклог в них и потом использовать на планировании спринта оценку в СП, которую поставили полгода назад бессмысленно. Даже если объем работы не поменялся, то изменилась сложность (люди не стоят на месте, они развиваются или деградируют + меняется состав команды) + могла изменится неопределенность (какие-то риски ушли, какие-то появились).
Story Points. Изобретение дьявола. Часть 2
Миф 5. Емкость команды в СП выражает ее эффективность и можно по ней сравнивать команды
Каждая команда уникальна и имеет свой набор навыков. У каждой команды свой контекст и своя производственная среда. И дело не в том что они по разному оценивают, а в том что они просто работают по разному. Даже если стандартизировать их способ мышления при оценке и способ выполнения работы, то ничего не получится. СП применяют для нематериального производство, которое происходит в разумах людей. И как в поговорке "к сожалению к рукам сотрудника прилагается и остальной человек".
Не нужно оценивать эффективность по количеству СП и тем более сравнивать 2 команды. ты сравниваешь одни уникальные усилия с другими уникальными усилиями. Оценивайте результат.
Миф 6. Сначала оценим СП аналитика, потом разработчика, потом тестировщика
При оценке СП участвуют все члены команды, каждый высказывают свою оценку сразу целиком по всей задаче. Даже аналитик, хотя он не разработчик и не знает как это точно закодить.
Работает такая оценка на опыте и СП предполагает именно усилия команды, а не отдельных ее членов.
Рассматривать команду надо не как группу индивидуумов, временно собранных вместе волею судеб, а как нечто неделимое, чёрный ящик, куда можно забросить задание и получить результат.
Что забавно, СП почти никогда не работает в группах людей, которые не понимают смысла работы друг друга и не работают на единой целью.
Миф 7. При декомпозиции задачи также декомпозируется ее оценка в СП
Вывод проистекает из мифа 5 и мифа 3. У каждой подзадачи будет свой набор рисков и своя сложность. Складывая 1 и 2 яблока ты получишь просто 3 яблока, а не одно большое.
Ну и плюс немного дополнительных умозаключений:
1. Нарезать истории на подзадачи никому кроме команды и не надо. Они сами себе её нарежут так, как им удобно. Декомпозиция нужна именно для увеличения знаний о задаче и удобства работы с ней. Не для оценки;
2. Оценивать подзадачи тоже не надо, никому не интересно, сколько будет делаться конкретная подзадача, всем интересен конечный результат - готовая задача.
Миф 8. СП можно складывать
Можно конечно попробовать складывать, но тут опять вылезает миф 3. Не складывается просто сложность и неопределенность.
Также можно посмотреть математически. Является ли базис СП линейным и обладает ли он свойством аддитивности? Можно ли сложить задачу в 3 СП и 2 СП? Полагаю в твоем случае тоже нет)
Также появляется интересный вывод - капасити это не сумма СП, а просто их количество.
Миф 9. СП лучше часов. Штуки задач лучше СП. NoEstimates!!!
СП необходимы для оценки усилий и дальнейшего выбора в контейнер времени наиболее важных задач (часто такой контейнер называют спринтом).
Часы нужны для прогнозирования того, сколько денег будет потрачено. Все сроки, дедлайны сводятся к одному - когда будет произведен возврат инвестиций, а это именно про деньги.
А штуки нужны для управления потоком и нагрузки на команду. WIP limit, inflow и вот это все.
Единственное преимущество, которые дают штуки задач относительно СП - это то что можно просто не тратить время на оценку. В остальном их точность прогнозирования, например с помощью Монте-Карло примерно одинаковая.
Миф 10. СП подходят для долгосрочного планирования
Из предыдущего мифа следует простой вывод. СП нужны только на коротком промежутке времени и применяются именно для решения "сколько работы уложится в итерацию". После запуска итерации смысл СП исчезает.
Так как оценка СП выражает объем, риски и сложность, то оценивать весь беклог в них и потом использовать на планировании спринта оценку в СП, которую поставили полгода назад бессмысленно. Даже если объем работы не поменялся, то изменилась сложность (люди не стоят на месте, они развиваются или деградируют + меняется состав команды) + могла изменится неопределенность (какие-то риски ушли, какие-то появились).
#мнение
Story Points. Изобретение дьявола. Часть 3
Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют велосити. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем "50/50, или сделаем или нет".
P.S. Мне нравятся СП, у них интересная концепция, но уже слишком много соблазнов их использовать неправильно. Надеюсь аджайл-коучи и СМы меня не похоронят)
Story Points. Изобретение дьявола. Часть 3
Также с точки зрения математики расчет среднего значения по несколькими спринтам есть довольно странное упражнение, которое называют велосити. По распределению скорее всего среднее находится левее медианы, так как подвержено выбросам. То есть вероятность велосити это даже меньше чем "50/50, или сделаем или нет".
P.S. Мне нравятся СП, у них интересная концепция, но уже слишком много соблазнов их использовать неправильно. Надеюсь аджайл-коучи и СМы меня не похоронят)
#полезности
Как не прибивай гвоздями объем работ, обязательно что-нибудь поползет
Немного поучаствовал в написании статьи со скиллсеттером, отговорил от некоторых распространенных ошибок и дал комментарий по способам отслеживания сроков. В целом похоже на один день начинающего проджекта, довольно занятно
Как не прибивай гвоздями объем работ, обязательно что-нибудь поползет
Немного поучаствовал в написании статьи со скиллсеттером, отговорил от некоторых распространенных ошибок и дал комментарий по способам отслеживания сроков. В целом похоже на один день начинающего проджекта, довольно занятно
Forwarded from skillsetter.io
📊 Как управлять IT-проектом: сроки, бюджет и скоуп (и чек-лист для проджекта!)
Представьте, что вы начинающий проджект. Вы недавно устроились в компанию и помогаете наставнику Джиму вести проект.
Незадолго до релиза Джиму приходится взять отпуск, и он передает вам все задачи. Через пару дней заказчик пишет, что нужно добавить новую фичу.
Вы растеряны. Что делать в первую очередь? Как перераспределить ресурсы и организовать работу проектной команды? Какие факторы нужно учесть?
В статье рассказываем о том, что такое проектный треугольник и как управлять его вершинами.
Статью написали вместе с Полиной Скалуновой, marketing project manager в Skyeng. Также вы найдете комментарии двух экспертов:
Елена Горопека, бизнес-аналитик и продакт-менеджер, поделилась советами по управлению скоупом.
Артем Летюшев, менеджер-аналитик Юмани, рассказал о способах управления сроками проекта.
#useful | @skillsetter x @harapeka x @junior_pm
Представьте, что вы начинающий проджект. Вы недавно устроились в компанию и помогаете наставнику Джиму вести проект.
Незадолго до релиза Джиму приходится взять отпуск, и он передает вам все задачи. Через пару дней заказчик пишет, что нужно добавить новую фичу.
Вы растеряны. Что делать в первую очередь? Как перераспределить ресурсы и организовать работу проектной команды? Какие факторы нужно учесть?
В статье рассказываем о том, что такое проектный треугольник и как управлять его вершинами.
Статью написали вместе с Полиной Скалуновой, marketing project manager в Skyeng. Также вы найдете комментарии двух экспертов:
Елена Горопека, бизнес-аналитик и продакт-менеджер, поделилась советами по управлению скоупом.
Артем Летюшев, менеджер-аналитик Юмани, рассказал о способах управления сроками проекта.
#useful | @skillsetter x @harapeka x @junior_pm
skillsetter.io
Как управлять IT-проектом: сроки, бюджет и скоуп
Рассказываем, что следует сделать до того, как добавить новую задачу в проект, и как выбрать оптимальное решение для ее реализации.
#полезности
Спринты есть, у нас скрам!
Дорогой читатель, я восхитился этой статьей, оцени её и ты. Она о том как использовать модный фреймворк без самого фреймворка.
https://vladimirmerkushev.medium.com/scream-guide-%D0%BA%D0%B0%D0%BA-%D0%B1%D1%8B%D1%82%D1%8C-agile-%D0%B8-%D0%BD%D0%B5-%D0%BC%D0%B5%D0%BD%D1%8F%D1%82%D1%8C%D1%81%D1%8F-3ad19ce4ad1c
Спринты есть, у нас скрам!
Дорогой читатель, я восхитился этой статьей, оцени её и ты. Она о том как использовать модный фреймворк без самого фреймворка.
https://vladimirmerkushev.medium.com/scream-guide-%D0%BA%D0%B0%D0%BA-%D0%B1%D1%8B%D1%82%D1%8C-agile-%D0%B8-%D0%BD%D0%B5-%D0%BC%D0%B5%D0%BD%D1%8F%D1%82%D1%8C%D1%81%D1%8F-3ad19ce4ad1c
Medium
Scream Guide. Как быть Agile и не меняться
Scream — это фреймворк, созданный как имитация Scrum, дающий невольным наблюдателям впечатление, что организация использует Scrum. Scream —…
#полезности
Проект по скрам? Hold on my beer
Тоже замечательная статья про то как правильно использовать скрам и не париться.
https://antonshell.me/post/drunk-scrum
Проект по скрам? Hold on my beer
Тоже замечательная статья про то как правильно использовать скрам и не париться.
https://antonshell.me/post/drunk-scrum
#рецепт
Как выходить менеджеру на новый уровень. Зарплатный. Часть 1
Здравствуй, предприимчивый читатель. Сегодня мы почитаем про тему зарплатного роста. Ну как мы, я просто перепечатал текст одного менеджера @revealed_dave, выглядит он очень пользительным, поэтому держи. Приятного прочтения.
Главный вопрос, который надо задать: Зачем рост на X в деньгах? Деньги не могут быть целью. Деньги — это ресурс чтобы что-то. Самому себе ответить на этот вопрос → хорошее решение.
Частые проблемы
1. Почти уверен, что у тебя «сильный» синдром самозванца и ты обесцениваешь свои навыки. Например, ты работаешь над симуляторами МКС для ESA, а не кнопочки в очередном приложении двигаешь. Субъективно, это звучит гораздо интереснее, чем «двигать кнопочки». Интереснее звучит → легче продать. А сегодня ты «презентовал что-то» саудитам. Предполагаю, что презентовал на английском (поправь, если неправ) → презентовать на английском = знать английский на достаточном для этого уровне. Большая часть менеджеров в РФ не обладает таким уровнем языка.
2. Ты сам себе создал потолок и от него танцуешь: у меня нет требуемых компетенций (оценка об рынок и домыслы), мне не будут платить больше чем (оценка об рынок и домыслы), например хочу рост х2 за 2 года (всего-то?).
3. Взял за основу большой горизонт планирования. А люди плохо видят будущее и систематически ошибаются в этом. Большой горизонт планирования приводит к тому, что ты:
- Меньше контролируешь прогресс достижения цели (трекшн);
- Пытаешься переварить больший объем информации за раз → демотивируешься;
- Чаще ошибаешься и позже видишь эти ошибки;
- никто не отменял 1 Закон Паркинсона
4. У тебя недостаточно компетенции для оценки и валидации своего уровня: Даннинг-Крюгер. И этот недостаток компетенций ты компенсируешь оценкой об рынок. А использовать рынок как один из основных источников данных о твоих навыках — значит полагаться на оценочные и иррациональные (люди не рациональны, Канеман) суждения людей, которым о твоих навыках ничего неизвестно. Собеседующие оценивают не тебя и твои навыки, а их проекцию тебя и их домыслы по поводу твоих навыков. Рынок нужен для сверки с реальностью, не более. Как сверяться с рынком — ниже.
Как выходить менеджеру на новый уровень. Зарплатный. Часть 1
Здравствуй, предприимчивый читатель. Сегодня мы почитаем про тему зарплатного роста. Ну как мы, я просто перепечатал текст одного менеджера @revealed_dave, выглядит он очень пользительным, поэтому держи. Приятного прочтения.
Главный вопрос, который надо задать: Зачем рост на X в деньгах? Деньги не могут быть целью. Деньги — это ресурс чтобы что-то. Самому себе ответить на этот вопрос → хорошее решение.
Частые проблемы
1. Почти уверен, что у тебя «сильный» синдром самозванца и ты обесцениваешь свои навыки. Например, ты работаешь над симуляторами МКС для ESA, а не кнопочки в очередном приложении двигаешь. Субъективно, это звучит гораздо интереснее, чем «двигать кнопочки». Интереснее звучит → легче продать. А сегодня ты «презентовал что-то» саудитам. Предполагаю, что презентовал на английском (поправь, если неправ) → презентовать на английском = знать английский на достаточном для этого уровне. Большая часть менеджеров в РФ не обладает таким уровнем языка.
2. Ты сам себе создал потолок и от него танцуешь: у меня нет требуемых компетенций (оценка об рынок и домыслы), мне не будут платить больше чем (оценка об рынок и домыслы), например хочу рост х2 за 2 года (всего-то?).
3. Взял за основу большой горизонт планирования. А люди плохо видят будущее и систематически ошибаются в этом. Большой горизонт планирования приводит к тому, что ты:
- Меньше контролируешь прогресс достижения цели (трекшн);
- Пытаешься переварить больший объем информации за раз → демотивируешься;
- Чаще ошибаешься и позже видишь эти ошибки;
- никто не отменял 1 Закон Паркинсона
4. У тебя недостаточно компетенции для оценки и валидации своего уровня: Даннинг-Крюгер. И этот недостаток компетенций ты компенсируешь оценкой об рынок. А использовать рынок как один из основных источников данных о твоих навыках — значит полагаться на оценочные и иррациональные (люди не рациональны, Канеман) суждения людей, которым о твоих навыках ничего неизвестно. Собеседующие оценивают не тебя и твои навыки, а их проекцию тебя и их домыслы по поводу твоих навыков. Рынок нужен для сверки с реальностью, не более. Как сверяться с рынком — ниже.
#рецепт
Как выходить менеджеру на новый уровень. Зарплатный. Часть 2
Цели
Поставь меньший горизонт планирования и разбей минимум на 2 цели. Каждую цель сделай амбициознее:
1. Вырасти по ЗП как минимум на ~40% через 6 месяцев.
2. Вырасти по ЗП как минимум на ~80% через 1 год.
3. Опционально, но я бы поставил третью цель: вырасти по ЗП на ~30% через 3 месяца. Следовательно, нужно будет поднять проценты в целях на полгода и год.
Меньше горизонт → легче видеть и управлять трекшном по целям. Если ты не достигнешь цели, это не страшно. Это всего-лишь значит, что нужно отрефлексировать (задать себе вопрос: почему не получилось?) → поменять план.
А с меньшим горизонтом планирования ты увидишь это раньше.
От цели составь план из гипотез в формате JTBD:
- Если я буду менять работу каждый год, то смогу обеспечить себе рост в 50% в год
- Если я схожу к Васе руководителю и договорюсь с ним о повышении ЗП, то смогу договориться на рост 40% каждые полгода
- Если я пройду курс Go Practice то указав свои результаты прохождения курса в резюме, я смогу претендовать на +20% ЗП при поиске
- и тп
И валидируй каждый пункт об реальность. Чем меньше ресурсов тратишь на валидацию, тем лучше. Как валидировать — большая задача, в этот текст не влезет. Например: чтобы проверить гипотезу про Go Practice, не нужно за него платить и проходить. Достаточно найти 5-10 людей, которые прошли и пообщаться с ними. Или вообще пообщаться с Ксюшей (продакт симулятора) или даже с Олегом (создатель симулятора). Или поискать инфу в интернете, вполне может быть, что кто-то уже задался этим вопросом и инфа просто лежит и ждет тебя.
Узнай, как ты можешь вырасти в текущей компании.
Сходи к руководителю и спроси «Вася, привет! Я хочу вырасти на 40% по ЗП в течение 6 месяцев. Что мне нужно для этого сделать? Как я могу это сделать?». Не предлагай ему решения, а дай руководителю самостоятельно сделать его работу.
Избавляйся от самозванца и собирай фактологию для аргументации роста по ЗП в текущей компании/на собесах:
1. Заведи дневник достижений и записывай туда свои, самые многообещающие, продуктовые/проджектовые гипотезы. После собирай фактологию: что действительно изменилось, как, в каких метриках и добавляй туда же. Это поможет тебе аргументированно отвечать на вопрос «почему мы должны дать тебе Х денег» и поможет докачать навыки: «презентация достижений», «системность», снизит влияние самозванца на твою оценку себя.
2. Составь профиль менеджера со списком компетенций, за которые по твоему, будут прямо сейчас платить 360к. Сравни свои компетенции с этим портретом. Выбери оттуда 2-5 приоритетных компетенций → составь план по их развитию, в плане обязательно укажи сроки/дедлайны (планируй на ~20% больше, чем можешь прожевать) → игнорируй все остальное. Тут может помочь эта карта навыков (это для продакта).
3. https://zamesin.me/ru-how-to-be-succesful-by-sam-altman, особенно пункт 2.
Как выходить менеджеру на новый уровень. Зарплатный. Часть 2
Цели
Поставь меньший горизонт планирования и разбей минимум на 2 цели. Каждую цель сделай амбициознее:
1. Вырасти по ЗП как минимум на ~40% через 6 месяцев.
2. Вырасти по ЗП как минимум на ~80% через 1 год.
3. Опционально, но я бы поставил третью цель: вырасти по ЗП на ~30% через 3 месяца. Следовательно, нужно будет поднять проценты в целях на полгода и год.
Меньше горизонт → легче видеть и управлять трекшном по целям. Если ты не достигнешь цели, это не страшно. Это всего-лишь значит, что нужно отрефлексировать (задать себе вопрос: почему не получилось?) → поменять план.
А с меньшим горизонтом планирования ты увидишь это раньше.
От цели составь план из гипотез в формате JTBD:
- Если я буду менять работу каждый год, то смогу обеспечить себе рост в 50% в год
- Если я схожу к Васе руководителю и договорюсь с ним о повышении ЗП, то смогу договориться на рост 40% каждые полгода
- Если я пройду курс Go Practice то указав свои результаты прохождения курса в резюме, я смогу претендовать на +20% ЗП при поиске
- и тп
И валидируй каждый пункт об реальность. Чем меньше ресурсов тратишь на валидацию, тем лучше. Как валидировать — большая задача, в этот текст не влезет. Например: чтобы проверить гипотезу про Go Practice, не нужно за него платить и проходить. Достаточно найти 5-10 людей, которые прошли и пообщаться с ними. Или вообще пообщаться с Ксюшей (продакт симулятора) или даже с Олегом (создатель симулятора). Или поискать инфу в интернете, вполне может быть, что кто-то уже задался этим вопросом и инфа просто лежит и ждет тебя.
Узнай, как ты можешь вырасти в текущей компании.
Сходи к руководителю и спроси «Вася, привет! Я хочу вырасти на 40% по ЗП в течение 6 месяцев. Что мне нужно для этого сделать? Как я могу это сделать?». Не предлагай ему решения, а дай руководителю самостоятельно сделать его работу.
Избавляйся от самозванца и собирай фактологию для аргументации роста по ЗП в текущей компании/на собесах:
1. Заведи дневник достижений и записывай туда свои, самые многообещающие, продуктовые/проджектовые гипотезы. После собирай фактологию: что действительно изменилось, как, в каких метриках и добавляй туда же. Это поможет тебе аргументированно отвечать на вопрос «почему мы должны дать тебе Х денег» и поможет докачать навыки: «презентация достижений», «системность», снизит влияние самозванца на твою оценку себя.
2. Составь профиль менеджера со списком компетенций, за которые по твоему, будут прямо сейчас платить 360к. Сравни свои компетенции с этим портретом. Выбери оттуда 2-5 приоритетных компетенций → составь план по их развитию, в плане обязательно укажи сроки/дедлайны (планируй на ~20% больше, чем можешь прожевать) → игнорируй все остальное. Тут может помочь эта карта навыков (это для продакта).
3. https://zamesin.me/ru-how-to-be-succesful-by-sam-altman, особенно пункт 2.
productframework.ru
Product Manager Skill Map
Карта навыков менеджера продукта с точки зрения Product Architecture Framework
#рецепт
Как выходить менеджеру на новый уровень. Зарплатный. Часть 3
Узнай, на каком этапе режется конверсия и как/почему рынок тебя так оценивает.
Прими, что рынок иррационален и даже джуну готовы платить 300к+ (пример: @artemletya)
Велика вероятность, что стоит докачать мета-навык «прохождение собесов». Там где-то точно режется конверсия, деталей больше дать не смогу, так как не хватает инфы. Но ты можешь сам понять, какой этап вызывает проблемы и почему.
1. Создай резюме-профиль с не своим именем, другим названием компаний в опыте и с ожиданиями по ЗП выше на 40%+, чем ты сам себя оцениваешь + обязательно прикладывай сопроводительное письмо. Также, на некоторых площадках можно откликаться «скрытно», типа djinni, geekjobs и тд. Твой работодатель не узнает что ты это делаешь → не нужно будет ему ничего объяснять. Все это можно делать удаленно, в свободное от работы время.
2. Откликайся на 5-20 вакансий в неделю. Не так важно куда, главное чтобы там была вилка по ЗП и описание вакансии базово соответствовало тому, что ты ищешь. Даже если ты пройдешь все этапы, а работу сменить не захочешь, то в конце всегда можно отказаться, сославшись на что угодно.
3. Собирай обратную связь: сколько откликов, сколько отказали/промолчали, сколько позвали на 1 собес, сколько отказали/промолчали после 1 собеса, сколько отказали/промолчали на 2 собесе и тд. Всегда задавай вопрос «почему?». Собирай ответы на этот вопрос. Можешь табличку завести :)
4. В зависимости от того, на каком этапе происходит потеря конверсии, ты сможешь тюнить только этот этап и не трогать другие.
5. Твое резюме + сопровод + поведение на собесах — это продукт. У него есть метрики. Узнай их, тюнь, а полезное и повторяемое (то, что масштабируется) утащи в свой основной профиль.
Например
- Если ты откликнулся на 20 вакансий и 15 отказали/промолчали → проблема в резюме или сопроводительном.
- Если 15 позвали на собес, но дальше отказали → проблема в том, как ты презентуешь себя рекрутерам.
- Если 10 позвали на этап общения с продактом, но дальше отказали/промолчали → проблема в презентации достижений продактам.
Решение этих 3 проблем — разные задачи, и чтобы понимать, какую из них нужно решать и как → нужно иметь фактологию перед глазами. Не в памяти, а именно перед глазами.
P.S. Текст не мой, Давида @revealed_dave.
Как выходить менеджеру на новый уровень. Зарплатный. Часть 3
Узнай, на каком этапе режется конверсия и как/почему рынок тебя так оценивает.
Прими, что рынок иррационален и даже джуну готовы платить 300к+ (пример: @artemletya)
Велика вероятность, что стоит докачать мета-навык «прохождение собесов». Там где-то точно режется конверсия, деталей больше дать не смогу, так как не хватает инфы. Но ты можешь сам понять, какой этап вызывает проблемы и почему.
1. Создай резюме-профиль с не своим именем, другим названием компаний в опыте и с ожиданиями по ЗП выше на 40%+, чем ты сам себя оцениваешь + обязательно прикладывай сопроводительное письмо. Также, на некоторых площадках можно откликаться «скрытно», типа djinni, geekjobs и тд. Твой работодатель не узнает что ты это делаешь → не нужно будет ему ничего объяснять. Все это можно делать удаленно, в свободное от работы время.
2. Откликайся на 5-20 вакансий в неделю. Не так важно куда, главное чтобы там была вилка по ЗП и описание вакансии базово соответствовало тому, что ты ищешь. Даже если ты пройдешь все этапы, а работу сменить не захочешь, то в конце всегда можно отказаться, сославшись на что угодно.
3. Собирай обратную связь: сколько откликов, сколько отказали/промолчали, сколько позвали на 1 собес, сколько отказали/промолчали после 1 собеса, сколько отказали/промолчали на 2 собесе и тд. Всегда задавай вопрос «почему?». Собирай ответы на этот вопрос. Можешь табличку завести :)
4. В зависимости от того, на каком этапе происходит потеря конверсии, ты сможешь тюнить только этот этап и не трогать другие.
5. Твое резюме + сопровод + поведение на собесах — это продукт. У него есть метрики. Узнай их, тюнь, а полезное и повторяемое (то, что масштабируется) утащи в свой основной профиль.
Например
- Если ты откликнулся на 20 вакансий и 15 отказали/промолчали → проблема в резюме или сопроводительном.
- Если 15 позвали на собес, но дальше отказали → проблема в том, как ты презентуешь себя рекрутерам.
- Если 10 позвали на этап общения с продактом, но дальше отказали/промолчали → проблема в презентации достижений продактам.
Решение этих 3 проблем — разные задачи, и чтобы понимать, какую из них нужно решать и как → нужно иметь фактологию перед глазами. Не в памяти, а именно перед глазами.
P.S. Текст не мой, Давида @revealed_dave.
#рецепт
Вопросы к собеседованию на проджекта. Часть 1
Здравствуй, начинающий читатель. Не будет предисловий, ты и так понял о чем этот пост.
От Андрея Лякина и сообщества PMI @pmin_ru
1. Что такое проект?
2. Что такое "управление проектом"? Расскажите, как управляли каким-нибудь проектом
3. Назови основные параметры проекта (треугольник, перевернутый, гексаэдр, октаэдр)
4. Чем проект отличается (и отличается ли вообще) от процесса?
5. Какие ты знаешь основные артефакты для управления проектом
6. В чем для тебя драйв от занятия такой работой?
7. Кто такой "РП"? В чем его отличие от ПМ?
8. Расскажи про свой самый феерический факап и что было потом?
9. Расскажи про свой самый крутой проект и как вы его таким сделали?
10. Клиент просит добавить в спецификацию продукта проекта несколько
новых фич, при этом у вас фикспрайс, большая часть проекта уже
сделана, сроки сдвигать нельзя... Что ты ответишь клиенту?
11. Чему новому ты научился в этом году? Какие навыки развили?
12. Какие прочитал книги и что из прочитанного взял в практику?
13. Какие сейчас у вас есть задачи и план по их достижению?
14. Что ты делаешь лучше других (укажи каких других) и почему тебе это важно?
15. Приведи примеры успешных и неуспешных проектов. Причины успеха и провала.
16. Нарисуй «Треугольник ограничений» и расскажите, как он работает
17. Гант. Дается общее описание простого проекта с перечнем задач и прошу
набросать диаграмму с расстановкой майлстоунов;
18. Как ты понимаешь понимание отчетную документацию? Что такое план-график, сметы, акты?
19. Как вообще происходит закрытие с заказчиком и подрядчиками? Расскажи про этот процесс.
20. Какие ресурсы по теме управления проектами для проф. общения, доп
информации, нетворкинга, обучения используешь?
21. Нужно составить календарный план. Какие инструменты будешь
использовать? Почему? Какие инструменты можно использовать
дополнительно?
23. Какие вообще инструменты знаете для создания календарного плана,
календарно-сетевого графика?
24. Зачем вообще нужно календарное планирование? А календарно-сетевое планирование? Чем они отличаются?
25. Опиши общий алгоритм твоих действий при абсолютно любой авральной/ критической ситуации в проекте.
Вопросы к собеседованию на проджекта. Часть 1
Здравствуй, начинающий читатель. Не будет предисловий, ты и так понял о чем этот пост.
От Андрея Лякина и сообщества PMI @pmin_ru
1. Что такое проект?
2. Что такое "управление проектом"? Расскажите, как управляли каким-нибудь проектом
3. Назови основные параметры проекта (треугольник, перевернутый, гексаэдр, октаэдр)
4. Чем проект отличается (и отличается ли вообще) от процесса?
5. Какие ты знаешь основные артефакты для управления проектом
6. В чем для тебя драйв от занятия такой работой?
7. Кто такой "РП"? В чем его отличие от ПМ?
8. Расскажи про свой самый феерический факап и что было потом?
9. Расскажи про свой самый крутой проект и как вы его таким сделали?
10. Клиент просит добавить в спецификацию продукта проекта несколько
новых фич, при этом у вас фикспрайс, большая часть проекта уже
сделана, сроки сдвигать нельзя... Что ты ответишь клиенту?
11. Чему новому ты научился в этом году? Какие навыки развили?
12. Какие прочитал книги и что из прочитанного взял в практику?
13. Какие сейчас у вас есть задачи и план по их достижению?
14. Что ты делаешь лучше других (укажи каких других) и почему тебе это важно?
15. Приведи примеры успешных и неуспешных проектов. Причины успеха и провала.
16. Нарисуй «Треугольник ограничений» и расскажите, как он работает
17. Гант. Дается общее описание простого проекта с перечнем задач и прошу
набросать диаграмму с расстановкой майлстоунов;
18. Как ты понимаешь понимание отчетную документацию? Что такое план-график, сметы, акты?
19. Как вообще происходит закрытие с заказчиком и подрядчиками? Расскажи про этот процесс.
20. Какие ресурсы по теме управления проектами для проф. общения, доп
информации, нетворкинга, обучения используешь?
21. Нужно составить календарный план. Какие инструменты будешь
использовать? Почему? Какие инструменты можно использовать
дополнительно?
23. Какие вообще инструменты знаете для создания календарного плана,
календарно-сетевого графика?
24. Зачем вообще нужно календарное планирование? А календарно-сетевое планирование? Чем они отличаются?
25. Опиши общий алгоритм твоих действий при абсолютно любой авральной/ критической ситуации в проекте.
#рецепт
Вопросы к собеседованию на проджекта. Часть 2
Вопросы от Евгения @Eugean1980 (прям огромный респект, но это даже не очень на джуна, повыше)
1. В каких направлениях ты развивался за последний год? Почему? Чему новому научился? Что именно ты делал для этого?
2. Приходилось ли тебе что-то кардинально менять в своей жизни, карьере? Что тебя на это подвигло? Как ты переживал это изменение?
3. Как часто ты слышишь в свой адрес вопрос «Тебе больше всех надо?» или тебе кажется, что окружающие так думают про тебя? В каких ситуациях?
4. Какие изменения в работе за последние один-два года были предложены лично тобой? В связи с чем ты их предложил? В чем именно заключалась твоя в роль в процессе их внедрения? Какой результат в итоге был получен?
5. Когда в работе у тебя возникают сложности, что помогает тебе идти до конца?
6. Как ты считаешь, насколько оправдано брать на себя дополнительную нагрузку в совместной работе с коллегами? Почему? В каких ситуациях, на твой взгляд, этого делать, точно не стоит?
7. Приведи пример того, как ты решил противоречия, возникшие в команде.
8. Приведи пример, когда ты пожертвовал личными целями ради достижения целей команды
9. Бывали ли у тебя ситуации, когда ты сделал для клиента что-то, что не обязан были делать (сверх обязательного, сверх положенного)? Какие цели преследовал? Что именно делал?
10. Приведи пример, что ты изменил в своей работе на основании обратной связи от важного стейкхолдера (внутреннего/внешнего).
11. Расскажи о своем опыте реализации самого масштабного проекта. Какая была цель? Какая роль была у тебя? Каков был результат?
12. Расскажи о ситуации, когда ты решал задачу, не имеющую аналогов в твоем опыте? Какое решение приняли? Рассматривались ли другие варианты? Почему?
13. Опишите проблемы, с которыми ты чаще всего сталкиваешься в работе. В чем ты видитшь их причины?
14. Какие решения тебе приходилось принимать? Приведи пример сложного решения. Что ты учитывал при принятии решения? Почему именно это? Чего бы хотел добиться? К чему это привело?
15. Опиши ситуацию, когда тебе пришлось изменить первоначальное решение? Почему ты это сделал? К чему этот привело?
16. Приведи пример, когда для решения задачи тебе приходилось выходить за рамки своих обязанностей, брать на себя дополнительную ответственность или ты делал что-то, что не обязан был делать (сверх обязательного / положенного/достигнутых договоренностей)? Что именно ты делал? Какие результаты были получены в итоге?
17. Вспомни свой неудачный опыт. Что это была за ситуация? В чем были причины неудачи? Чем был полезен для тебя этот опыт?
18. Расскажите о последней ситуации, когда тебе необходимо было реализовать поставленную руководством задачу. Как ты планировал ее выполнение (ресурсы, сроки и пр.)
19. Расскажите про сложную задачу, которую удалось реализовать вопреки обстоятельствам? За счет чего тебе это удалось? Каков был твой план? Как ты действовал?
20. В чем на твой взгляд заключаются твои сильные стороны? Что тебе необходимо в себе изменить, развивать? Как ты это делаешь/планируешь делать?
21. Как ты думаешь тебя оценивают другие люди? В чем они видят твои сильные/слабые стороны?
22. Расскажи о ситуации, когда тебе потребовалось приложить усилия, чтобы отстоять свою позицию, повлиять на других. Какой была твоя цель? Как ты действовал, какой был результат?
23. Как ты восстанавливаешь силы?
24. Как ты справляешься с собой в сложных эмоциональных ситуациях? Приведи примеры.
25. Как ты подбираешь людей и формируешь свою команду? Что для тебя важно? Совершал ли ты ошибки в найме? Что для тебя может стать веской причиной для увольнения сотрудника?
26. Что ты делаешь для развития своей команды? Как продвигаете лучших? Приведите примеры людей, которые выросли из твоей команды. Есть ли у тебя преемник? Как ты его развиваешь?
27. Сталкивался ли ты с ситуацией конфликта интересов с людьми одного уровня с тобой из других подразделений? Какова была твоя цель? Как действовал? Чего добился в результа
Вопросы к собеседованию на проджекта. Часть 2
Вопросы от Евгения @Eugean1980 (прям огромный респект, но это даже не очень на джуна, повыше)
1. В каких направлениях ты развивался за последний год? Почему? Чему новому научился? Что именно ты делал для этого?
2. Приходилось ли тебе что-то кардинально менять в своей жизни, карьере? Что тебя на это подвигло? Как ты переживал это изменение?
3. Как часто ты слышишь в свой адрес вопрос «Тебе больше всех надо?» или тебе кажется, что окружающие так думают про тебя? В каких ситуациях?
4. Какие изменения в работе за последние один-два года были предложены лично тобой? В связи с чем ты их предложил? В чем именно заключалась твоя в роль в процессе их внедрения? Какой результат в итоге был получен?
5. Когда в работе у тебя возникают сложности, что помогает тебе идти до конца?
6. Как ты считаешь, насколько оправдано брать на себя дополнительную нагрузку в совместной работе с коллегами? Почему? В каких ситуациях, на твой взгляд, этого делать, точно не стоит?
7. Приведи пример того, как ты решил противоречия, возникшие в команде.
8. Приведи пример, когда ты пожертвовал личными целями ради достижения целей команды
9. Бывали ли у тебя ситуации, когда ты сделал для клиента что-то, что не обязан были делать (сверх обязательного, сверх положенного)? Какие цели преследовал? Что именно делал?
10. Приведи пример, что ты изменил в своей работе на основании обратной связи от важного стейкхолдера (внутреннего/внешнего).
11. Расскажи о своем опыте реализации самого масштабного проекта. Какая была цель? Какая роль была у тебя? Каков был результат?
12. Расскажи о ситуации, когда ты решал задачу, не имеющую аналогов в твоем опыте? Какое решение приняли? Рассматривались ли другие варианты? Почему?
13. Опишите проблемы, с которыми ты чаще всего сталкиваешься в работе. В чем ты видитшь их причины?
14. Какие решения тебе приходилось принимать? Приведи пример сложного решения. Что ты учитывал при принятии решения? Почему именно это? Чего бы хотел добиться? К чему это привело?
15. Опиши ситуацию, когда тебе пришлось изменить первоначальное решение? Почему ты это сделал? К чему этот привело?
16. Приведи пример, когда для решения задачи тебе приходилось выходить за рамки своих обязанностей, брать на себя дополнительную ответственность или ты делал что-то, что не обязан был делать (сверх обязательного / положенного/достигнутых договоренностей)? Что именно ты делал? Какие результаты были получены в итоге?
17. Вспомни свой неудачный опыт. Что это была за ситуация? В чем были причины неудачи? Чем был полезен для тебя этот опыт?
18. Расскажите о последней ситуации, когда тебе необходимо было реализовать поставленную руководством задачу. Как ты планировал ее выполнение (ресурсы, сроки и пр.)
19. Расскажите про сложную задачу, которую удалось реализовать вопреки обстоятельствам? За счет чего тебе это удалось? Каков был твой план? Как ты действовал?
20. В чем на твой взгляд заключаются твои сильные стороны? Что тебе необходимо в себе изменить, развивать? Как ты это делаешь/планируешь делать?
21. Как ты думаешь тебя оценивают другие люди? В чем они видят твои сильные/слабые стороны?
22. Расскажи о ситуации, когда тебе потребовалось приложить усилия, чтобы отстоять свою позицию, повлиять на других. Какой была твоя цель? Как ты действовал, какой был результат?
23. Как ты восстанавливаешь силы?
24. Как ты справляешься с собой в сложных эмоциональных ситуациях? Приведи примеры.
25. Как ты подбираешь людей и формируешь свою команду? Что для тебя важно? Совершал ли ты ошибки в найме? Что для тебя может стать веской причиной для увольнения сотрудника?
26. Что ты делаешь для развития своей команды? Как продвигаете лучших? Приведите примеры людей, которые выросли из твоей команды. Есть ли у тебя преемник? Как ты его развиваешь?
27. Сталкивался ли ты с ситуацией конфликта интересов с людьми одного уровня с тобой из других подразделений? Какова была твоя цель? Как действовал? Чего добился в результа
#рецепт
Вопросы к собеседованию на проджекта. Часть 3
28. Бывали ли ситуации, в которых вы чувствовали какое-то напряжение / когда вы понимали, что что-то идет не так во взаимоотношениях с коллегами? Расскажи подробнее о том, в какой момент и по каким признакам ты заметил напряжение? Как ты действовал и как развивалась ситуация?
29. Расскажи о своем профессиональном достижении/проекте, которым ты гордишься. Какова история возникновения проекта? Что ты предпринял, чтобы достичь успеха? Что бы могло тебя мотивировать повторить это достижение или даже превзойти его?
31. Какой твой предыдущий опыт мог бы помочь тебе в новой роли и почему? Какие еще знания/опыт могли бы тебе пригодиться в новой роли?
32. Почему ты считаешь, что эта позиция тебе подходит и почему ты подходишь на эту позицию?
33. Как и где ты пополняешь свои профессиональные знания? Приведи пример.
34. Какая задача в прошлом опыте была для тебя самой интересной? Какой работой тебе хочется заниматься больше всего?
35. Кого из знакомых ты можешь назвать успешным человеком и почему?
36. Что для тебя важно/ценно в работе и в жизни? Отвечает ли данная роль твоим личным ценностям?
Вопросы к собеседованию на проджекта. Часть 3
28. Бывали ли ситуации, в которых вы чувствовали какое-то напряжение / когда вы понимали, что что-то идет не так во взаимоотношениях с коллегами? Расскажи подробнее о том, в какой момент и по каким признакам ты заметил напряжение? Как ты действовал и как развивалась ситуация?
29. Расскажи о своем профессиональном достижении/проекте, которым ты гордишься. Какова история возникновения проекта? Что ты предпринял, чтобы достичь успеха? Что бы могло тебя мотивировать повторить это достижение или даже превзойти его?
31. Какой твой предыдущий опыт мог бы помочь тебе в новой роли и почему? Какие еще знания/опыт могли бы тебе пригодиться в новой роли?
32. Почему ты считаешь, что эта позиция тебе подходит и почему ты подходишь на эту позицию?
33. Как и где ты пополняешь свои профессиональные знания? Приведи пример.
34. Какая задача в прошлом опыте была для тебя самой интересной? Какой работой тебе хочется заниматься больше всего?
35. Кого из знакомых ты можешь назвать успешным человеком и почему?
36. Что для тебя важно/ценно в работе и в жизни? Отвечает ли данная роль твоим личным ценностям?
#рецепт
Вопросы к собеседованию на проджекта. Часть 4
Вопросы от [https://t.me/iampmclub](https://t.me/iampmclub) (немного порезал, в исходных было немного треша):
1. Какие этапы есть в предиктивном жизненном цикле ПО?
2. Чем анализ отличается от проектирования?
3. Как происходит снятие с эксплуатации?
4. Какая модель лучше: waterfall, V образная модель,
спиральная модель, инкрементная модель для проекта с фикс-прайсом?
5. Кто такие бизнес-аналитик и системный
аналитик? В чем их отличие?
6. В чем разница между функциональными и
нефункциональными требованиями? Приведи примеры обоих
7. Что такое BPMN, IDEF0, EPC, UML? В чем их отличие по опрделению?
8. Что такое техническое задание?
9. Что такое API?
10. Что такое архитектура ПО?
11. Что такое backend и frontend? Что такое клиент-сервер? Расскажи примеры взаимодействия
12. В чем отличие БД от СУБД?
13. Что такое REST, SOAP, GraphQL?
14. Что такое json/xml/html?
15. Что такое git flow?
16. Что такое commit, merge, feth, push, pull?
17. Как отличить баг от CR (change request)?
18. Как определить серьезность (severity) и приоритет
(priority) бага (дефекта)?
19. Что такое пирамида тестирования?
20. Когда нужны автотесты?
21. Какие нужны артефакты к релизу?
Вопросы к собеседованию на проджекта. Часть 4
Вопросы от [https://t.me/iampmclub](https://t.me/iampmclub) (немного порезал, в исходных было немного треша):
1. Какие этапы есть в предиктивном жизненном цикле ПО?
2. Чем анализ отличается от проектирования?
3. Как происходит снятие с эксплуатации?
4. Какая модель лучше: waterfall, V образная модель,
спиральная модель, инкрементная модель для проекта с фикс-прайсом?
5. Кто такие бизнес-аналитик и системный
аналитик? В чем их отличие?
6. В чем разница между функциональными и
нефункциональными требованиями? Приведи примеры обоих
7. Что такое BPMN, IDEF0, EPC, UML? В чем их отличие по опрделению?
8. Что такое техническое задание?
9. Что такое API?
10. Что такое архитектура ПО?
11. Что такое backend и frontend? Что такое клиент-сервер? Расскажи примеры взаимодействия
12. В чем отличие БД от СУБД?
13. Что такое REST, SOAP, GraphQL?
14. Что такое json/xml/html?
15. Что такое git flow?
16. Что такое commit, merge, feth, push, pull?
17. Как отличить баг от CR (change request)?
18. Как определить серьезность (severity) и приоритет
(priority) бага (дефекта)?
19. Что такое пирамида тестирования?
20. Когда нужны автотесты?
21. Какие нужны артефакты к релизу?