Так ли хороши OKR в любой ситуации? Есть ли способы сделать методологию более понятной, легче развертываемой и не такой требовательной к количеству сил для поддержания? Делюсь личным опытом, показываю реальные документы. В тексте бонусы — наш шаблон для организации OKR в Notion, а в конце ссылка на перевод статьи про альтернативный подход к постановке целей, именуемый GEM.

Работая над подходом к формированию целей и организации команды, я наткнулся на статью Кэтрин Китинг из Ad Hoc, описывающую формат постановки целей именуемый GEM (Goal -> Experiment -> Measure). Этот подход кажется мне интересным и доступным для внедрения, испытаю его на себе и после коррекций планируем попробовать внутри. Статья впервые публикуется в переводе на русский. Ссылка на оригинал ниже.

А также зачистки всего связанного с пользователем и созданного им контента.

Пользователям AppStore Connect разлетаются письма с просьбой заглянуть на свои App Review Page, чтобы прочесть письмо счастья. Если коротко, то приложения без кнопки создания запроса на удаление аккаунта и всех связанных с ним данных, включая сгенерированный пользователем контент, в AppStore больше не пропустят.

Зачем это читать?

Понять текущее реальное состояние рынка ноукод и решить идти в этот рынок для заработка и специализации или нет.

Определить пригодится ли ноукод в том чем сейчас занимаешься.

Я часто слышу от владельцев бизнеса сомнения и неуверенность в сторону собственной команды разработки. Самое частое недовольство — срыв сроков и удорожание работ. При этом команда довольно логично объясняет причины и того, и другого, но уровень доверия к ней начинает падать. 

Любопытно, почему до сих пор никто не говорит о том, как создать фундамент для уверенности в своей it-команде. Понимание процессов разработки для гендира — это его безопасность и спокойствие. Да, не каждый собственник бизнеса имеет технический бэкграунд. Но каждый, так или иначе, сталкивается с разработкой, цифровизацией или трансформацией бизнеса. При этом бизнес измеряет результаты деньгами. Разработка — количеством успешных релизов, устраненных багов и итоговой бесперебойной работой продукта. Но и те и другие фактически делают одно большое дело — создают качественный продукт, полезный для конечного клиента и создающий выручку. 

Как же предпринимателям без технических знаний понять программистов и подружиться с разработкой? Я уверен, что залог успеха — партнерские отношения между бизнесом и инженерами. У инженеров есть видение, мнение и экспертиза. А у бизнеса есть свои цели. В то же время, инженерия — это всегда расходная статья бюджета, а не доходная. Либо компания, потратив деньги на разработку, получит профит, либо разработка, с точки зрения бизнеса, просто сжигает бюджет. Технический склад ума разработчиков зачастую концентрируется на красивом коде, использовании best practice,  настройке, рефакторинге. На это команде разработки требуется дополнительное время. А бизнес знает, что если в определенный момент времени потребность клиента не удовлетворена, позже она просто теряет смысл. Давайте разберемся, почему возникают проблемы в общении и как можно их устранить.