All streams
Search
Write a publication
Pull to refresh
1
0
Send message

Привет. Чуть ранее статья была с примерами из нашей практики: https://habr.com/ru/companies/ingos_it/articles/862030/

Спасибо за интересную статью. Никогда не занимался стартапами и собственным бизнесом, а вот бизнес-стратегиями в корпорациях - да. Действительно пласт информации в области разработки стратегии - огромный. Читая статью почему-то вспомнилась книга "Лидер и племя" и тезисы разработки стратегии из неё, - мне они помогали проверять согласованность некоторых сформулированных стратегий на практике. Ниже делюсь основными (за деталями можно обратиться к книге).

Руководство по разработке стратегии:

  • Стратегии основаны на осмысление внешней среды, а не высших устремлений племени

  • Стратегии проваливаются в 70% случаев (исследовангие, 1999 г., М. Корби и др.)

  • Стратегия - исследовательский процесс, в который нужно вовлечь как можно больше людей

  • Важен настрой на сотрудничество и инновации для разработки стратегии, которую люди захотят воплотить

Пять компонентов стратегии:

  1. Ценности (базовые)

  2. Благородная цель

  3. Результаты (успех в настоящем)

  4. Активы (потенциал для непрерывного величия)

  5. Действия

После определения 1 и 2, следует обсудить 3 темы:

  1. Чего хотим (каких результатов добиваемся)?

  2. Что у нас есть (какие у нас имеются активы)?

  3. Что мы будем делать (какими будут наши действия)?

Тестовые вопросы:

  1. Хватит ли активов для достижения результатов?

  2. Хватит ли активов для обеспечения действий?

  3. Приведут ли такие действия к достижению результатов?

Советы коуча

  • Укажите на осязаемую пользу от наличия общих ценностей и благородной цели

  • Поинтересуйтесь у посторонних людей какими активами располагает ваше племя (со стороны видно лучше, чем изнутри). Лидеры часто приглашают экспертов

  • Если стратегия проваливается, посмотрите чем ещё племя хочет заняться (если ещё хочет), т. к. взаимоотношение в племени сохраняется

Интересный тезис про ответственность за результат и принятие ошибок. По опыту действительно непросто сообщить об ошибке или признать ошибку. В статье есть скрин как это может выглядеть на уровне эксперта. Интересно как принцип применяется на уровне менеджмента, например, как обычно поступают техлиды, чтобы поддерживать данный принцип у ребят? Ведь у них наверняка есть противоречие: ошибка = "плохо" (в том числе пред заказчиком или руководителем), с другой стороны ошибка действительно может способствовать развитию.

Ещё интересный тезис про роли и в частности документацию.
Про роли: кажется часто новичок может иметь потребность в определении роли за него, поскольку нуждается в помощи в этом вопросе, так как неопределённость велика и предложенный вариант с волонтёрством или выбором предложений от техлидов может быть не простой задачей. Как тогда поступаете?

Про документацию: "есть ребята, что совсем не любят писать документацию, при этом все задачи выполняют очень качественно. Мы по максимуму освободили их от писанины", - пример показался рисковым, так как будут те, кто делают что-то "классное" и те, кто делает что-то типа "писанина". И ещё цитата: "на потом мы откладываем работу с документацией. «Потом» наступает, когда задач мало", - выглядит как отложенная работа с техдолгом; в народе говорят, что техдолг лучше не накапливать... Возможно детальнее можете пояснить свой пример, картинка пока не сложилась, но заинтересовало (может это команды формата Джордан + Пипен, если уместна такая аналогия).

В моём случае стараюсь в замен предлагать принцип сервиса "под ключ": чтобы работа была сделана качественно и полноценно, надо быть готовым решить в том числе рутинные задачи, не только сливки собирать.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity

Specialization

Scrum Master
Lead
Git
English
JavaScript
SQL
Scrum
Agile