BI-проекты: 5 причин, почему они выходят за рамки бюджета (и как этого избежать)
Если вы хоть раз участвовали во внедрении BI-системы — знаете, как легко проект может уйти не туда: – бюджет трещит по швам, – сроки съедены интеграцией и доработками, – пользователи по-прежнему делают аналитику в Excel.
Мы в GlowByte собрали в статье практический разбор типичных ошибок, которые чаще всего приводят к перерасходу бюджета и снижению отдачи от BI-проектов.
Плюс: даём самодиагностический чек-лист и PDF-гайд, где перечислены все организационные, финансовые и технические риски BI-проектов.
Открытый проект редактора Neovim имеет уже более 100 ИИ-плагинов сейчас. Их список привёл разработчик решение Colin Kennedy. Некоторые из плагинов в списке находятся в разработке или могут быть не полностью ориентированы на редактор Neovim.
В прошлом году усиленно начал пользоваться AI (LLM) тулами и словил жуткую волну грусти-печали после 5-6 месяцев использования. Для меня самым сложным стало не то, что код в целом может писать LLM, а осознание того, то в общем-то это и не так важно. Гораздо важнее появился абстрактный вопрос зачем его вообще писать если завтра всё может поменяться настолько быстро что глазом не моргнешь.
Погрустив и поболев буквально и походив по книжным магазинам наткнулся на интересную книгу - The Art of Excellent Products: Enchanting Customers with Premium Brand Experiences by Riccardo Illy. И эта книга попала настолько, что понял как разрешить (на текущий момент), моральную дилемму с AI кодом, когда ты сам не пишешь код, а его пишет AI - через этические принципы.
На мой взгляд этические принципы дают три возможности:
Ограничения или фокус - зафиксировав принципы, можно фокусироваться только на том, что действительно важно и отбрасывать / deprioritize то, что не согласуется с этими принципами.
Гибкость при принятии решений - зная ограничения и имея этический фокус, можно при необходимости быстрее принимать ответственные решения, но при этом не жертвовать тем, что этически важно для компании / продукта.
Доверие - имея ограничения в виде выбранных этических принципов, ценности продукта / компании могут стать более устойчивыми к кризисам - что в итоге может дать больше доверия продукту для конечного пользователя. В теории:)
Поэтому с начала года я начал думать над принципами / ценностями / values и пытаться понять, какие подходят - и почему.
вышел из digital чтобы написать ручками в блокнотике:)
Для себя выделил три группы (пока что): - Приложения, игры и персональные принципы.
Например для приложений пока пришел к такому списку:
Удобство
Простота
Безопасность
Долговечность
Полезность
Для игр (так как это хобби, немного другие принципы):
Полезность
Творчество
Развлечение
Вызов
На текущий момент (май), 5 месяц тестирования - и могу честно сказать что стало гораздо проще фокусироваться на проблеме и решении чем раньше. Уверен что с развитием AI многое ещё изменится - но как будто это может стать мостиком для работы с ним с морально - этической стороны (особенно когда нужно торговаться / выбирать между быстрее - качественнее).
Ещё завел телеграм канал - https://t.me/devethics, в который стал собирать ценности / принципы которые внезапно стал открывать у других людей и компаний (продуктовых, электронных) и т.д.. Пока назвал этика разработчика:)
Надеюсь что пост чем нибудь вдохновит и окажется полезным :-)
Пожалуйста делитесь своими мыслями в комментариях:-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией:-)
Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).
Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.
ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)
20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.
Несколько информационных моментов.
1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО
Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.
2. Вебинары РБПО-направленности
Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:
Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.
3. Сертификация ФСТЭК
В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?
Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).
PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.
PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):
PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);
PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);
продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.
Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.
Работа каждого руководителя начинается с PDCA (Plan–Do–Check–Act)
Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!
Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.
В целом по способности выстроить всю цепочку от планирования до развития можно оценить любого руководителя. Каждый этап имеет свой вес в зависимости от специфики работы. Руководитель, исходя из своих личных особенностей и контекста бизнеса, может активнее участвовать в одних звеньях цепочки и делегировать другие. Полностью вложиться конечно можно, но гораздо спокойнее, если часть элементов делегировать, оставив себе наиболее критичные.
Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.
Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.
Руководителю лучше заранее решить, за что браться самому, а что делегировать для обеспечения полноты управленческой цепочки. Ну или надеется на "авось", а потом расхлебывать. В нашем случае девочка планировала, её отец брался за работу и развитие. Но цепочка была неполной как раз из-за отсутствия контроля — никто по-настоящему не отвечал за результат. Вот и получили то, что получили.
Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.
Есть 1000 и 1 способ организовать продуктовую команду, и каждый со своими преимуществами и недостатками. Как тут выбрать и не ошибиться? (*ﾉωﾉ)
Наш CPO Саша Бондаренко собрал и описал более 12 моделей команд. У каждой указал, какому типу компаний она подойдет, а также дал инструкцию по подбору «той самой». Получился большой материал, который мы разбили на несколько частей.
Спрос на IT-специалистов в 2025 году близок историческому минимуму и продолжает падать — по многим направлениям количество IT‑вакансий стало меньше, чем в самые тяжёлые времена ковида.
С конца 2022 года многие IT-компании во всём миру уволили примерно 635 тысяч сотрудников.
Эксперты винят в этой ситуации спад выручки, закрытие проектов, а также автоматизацию и внедрение нейросетей, которые снимают ощутимую часть работы. Специалисты говорят, что такие события будут прогрессировать по мере совершенствования ИИ. Под угрозой оказались даже сеньоры с 15-летним опытом и специалисты Microsoft, Google, Tesla, eBay и PayPal.
Что такое чистая архитектура: основные особенности
Чистая архитектура — это подход к проектированию систем, который предполагает независимость от фреймворка и вообще от внешних компонентов. Выделяем слой use-кейсов, слой сущностей, UI и презентер — и теперь эти слои и есть наши фреймворки. Поэтому реальный фреймворк в чистой архитектуре можно использовать как инструмент, а не перестраивать весь проект под его ограничения.
Как, по сути, работает чистая архитектура
Какие еще свойства чистой архитектуры важны:
Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.
Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.
Большой материал о том, на каком проекте была внедрен этот подход и почему выбрали именно его, читайте в блоге.
❓Разработчик и стартап: работать | основать | избегать?
В новом выпуске Sravni Tech Podcast обсуждаем, куда податься разработчику: пойти работать в стартап, рискнуть и запустить свой или держаться подальше от “стартапной суеты”? Наш гость — Илья Хрусталёв, основатель Foodfox (тот самый, что стал «Яндекс.Едой»).
В выпуске: 📌Работа в ИТ-стартапе: ожидание vs реальность 📌Жизненный цикл стартапа (и когда это уже не стартап?) 📌Запускаем свой бизнес в ИТ. Что важно учесть? 📌Различия стартапов в России и США. Где проще получить инвестиции?
Если в компании несколько команд, хорошая идея — время от времени переводить спецов с проекта на проект. Особенно это полезно для тех разработчиков, темп работы которых чуть ниже, чем в среднем по больнице. Новый проект поможет им увеличить производительность, а тимлиду — найти уязвимости в обеих командах.
Разберем, как это работает:
Новая среда и культура могут вдохновить разработчика на новые идеи и подходы, которые он не рассматривал ранее. Иногда смена обстановки может повысить мотивацию специалиста и помочь ему переосмыслить методы работы.
Обратная связь от новой команды поможет найти точки роста или новые, более эффективные инструменты. А всё вместе это может благотворно влиять на продуктивность разработчика.
Разнообразие задач помогает нащупать как пробелы, так и темы, в которых разработчик чувствует себя как рыба в воде. Кроме того, если внимание иногда переключается с задачи на задачу, улучшаются навыки и растет уверенность.
Обмен опытом позволит специалисту перенять лучшие практики и подходы у новых коллег, а это никогда не бывает лишним. Плюсом опять же потенциальный рост продуктивности — новые подходы и процессы могут помочь.
Идентификация проблем. Если разработчик работал медленно в одной команде, но быстро в другой — возможно, в первой проблемы. Они могут быть связаны с коммуникацией или с постановкой задач, но проверить точно стоит.
Главное при ротации — приставить к разработчику более опытного ментора. Так человеку будет легче адаптироваться в новой среде и получить необходимые знания для повышения продуктивности.
Больше советов по этой теме читайте в нашей статье. Она поможет выстроить работу команды разработки таким образом, чтобы дедлайны не срывались.
Президент РФ Владимир Путин в рамках «перечня поручений по итогам пленарного заседания и посещения выставки Форума будущих технологий, включая встречи с учёными», поручил Правительству РФ рассмотреть вопрос о создании национального суперкомпьютерного центра.
«С учётом ранее данных поручений рассмотреть вопрос о создании национального суперкомпьютерного центра, предусмотрев возможность предоставления российским исследователям доступа к его вычислительным мощностям и обратив внимание на необходимость подготовки кадров для данного центра».
Раньше (до того как машины стали стоить как квартира) замечал несколько раз - вот выберешь себе новую машину и вдруг в городе их оказывается уже очень много. Вот едет и вот еще. И потом начинаешь замечать, что их реально много стало вокруг.
На самом деле, их конечно же не стало больше, просто мы их стали замечать.
Такое наше поведение является проявлением эффекта Пигмалиона (Розенталя) и является одним из когнитивных искажений (ошибок мышления - обожаю эту тему, вот и сюда ввернул).
Эффект Пигмалиона - ожидания человека определяют его действия.
Психологи Роберт Розенталь и Ленора Якобсон провели эксперимент: в начале учебного года они выделили учеников из разных классов начальной школы, которые по результатам теста оказались более талантливыми и обладали более высоким IQ, чем их одноклассники. На самом деле никаких выдающихся способностей у них обнаружено не было и ученики были выбраны случайно, однако учителям сообщили обратное. Повторное тестирование в конце года показало, что результаты «одарённых» учеников в среднем улучшились, а показатель IQ увеличился.
Дело в том, что наш мозг с трудом отличает восприятие и ожидание. Социолог Роберт Мёртон описал самосбывающиеся пророчества, к которым относится эффект Пигмалиона, как самогипноз. Имея изначально убеждение о себе или других, мы влияем на действительность и делаем так, что оно становится правдой. Этот психологический феномен позволяет целенаправленно или случайно влиять на реальность.
А что автомобиль?
Решив купить новый автомобиль мы перестроили внутренние фильтры восприятия информации и начали по другому видеть ситуацию - буквально выхватывать из автомобильного потока ту самую марку.
Отсюда есть 2 интересных следствия:
1. Просто формулируя цели — вы уже настраиваете себя.
Сформулировав цель вы получите результат больше, чем если не сформулируете и будете просто «копать-бежать».
Это лучше чем ничего, но точно недостаточно чтобы сделать прорыв.
OKR служит хорошей формулой для формулирования целей.
2. От ожиданий руководителя зависит результат сотрудников.
Руководитель, который думает что его окружают «дэбилы», получит результат сильно хуже, чем тот кто будет верить в своих сотрудников и доверять им. Мои ребята точно способны на большее!
А знаете чей слоган «для способных на большее»? Пишите в комментариях
Неудивительно, что эти ребята сейчас активно внедряют OKR. Это уже становится частью их культуры.
⛵️Без кого не выплывем: 4 ключевые роли в OKR-проекте
Одна из базовых причин, почему так много неудачных внедрений OKR - OKR не рассматривается в компании как проект трансформации.
И если уж компания решает, что помимо красиво сформулированных амбициозных целей им еще нужен результат, мы запускаем настоящий проект и собираем под него команду.
Представьте, что для выполнения сложной миссии нам нужна команда, почти, как на пиратском корабле🏴☠️.
Наш опыт показывает, что есть 4 ключевые роли, без который наш корабль никуда не поплывет.
Итак.
Для успешного внедрения OKR как проекта нам понадобятся следующие роли.
🔶 Лидер проекта внедрения OKR — главный в проекте, это по сути капитан корабля. Обычно эту роль на себя берет кто-то из ТОП-менеджеров. Он напрямую заинтересован в успехе проекта и обладает управленческими компетенциями. Как и любой бывалый капитан, он понимает важность человеческой составляющей в проекте изменений.
Ключевые его задачи:
✅ вовлекать ТОП-менеджеров и других участников проекта;
✅ управлять изменениями;
✅ обеспечивать ресурсами участников проекта.
🔶 OKR-коуч — главный эксперт по OKR. Это тот самый мудрец, обладающий секретными знаниями о сокровищах, без которых команда не реализует проект. Работает на уровне организации и ТОП-менеджеров, а не команды. Обладает обширной практикой и набором инструментов, которые подбирает под конкретную ситуацию, в том числе управления изменениями. Чаще это приглашенный эксперт.
🔶 OKR-мастер работает на уровне команды, а не компании. Он задает ритм, помогает грести в верном направлении через декомпозицию целей и выстраивание регулярного процесса изменений. С его участием команда системно добивается бОльших результатов. И точно доплывет быстрее, чем без него.
🔶 OKR-Strategist отвечает за сборку общего дерева целей по компании. Является экспертом в декомпозиции целей и работе с метриками. Его ценность в том, чтобы помочь компании правильно распределить ресурсы между различными целями и выстроить регулярный процесс мониторинга.
Стали выделять эту роль, когда выяснили, что в компании никто не отвечает за сборку общего дерева целей, каждый за свой кусочек.
У нас уже есть курс для OKR-мастеров. И мы планируем запустить обучение и по другим ролям, чтобы у компаний была возможность собрать полноценную команду и запускать изменения.
Поэтому сейчас я провожу бесплатные интенсивы в закрытом телеграм-чате. Подробности обучения и ссылка на чат в моем телеграм-канале.
Вы показывали хорошие результаты на своей текущей позиции, были активны и хотели роста. Вы были хорошим экспертом и профессионалом.
Поэтому начальство и сделала вас руководителем, чтобы вы могли передать свою экспертизу и опыт новым сотрудникам.
Уже в роли руководителя вы брали самые сложные задачи на себя, как самый большой эксперт в команде.
Ваша экспертная мышца вновь прокачивалась значительное сильнее управленческой, еще очень слабой и не такой развитой.
В период кризисов вы также подключали свою экспертизу и опыт. Решения надо принимать быстро и максимально эффективно. Не до тренировок, дела делать надо.
В итоге в большинстве кризисных ситуациях (а последние лет 5 только такие и есть) вы добивались результата использую сильные экспертные мышцы. У управленческой мышцы даже не было шанса стать настолько же развитой, как экспертная.
Как это изменить?
В организме у нас тоже есть сильные мышцы - агонисты/антагонисты (двигатели), стабилизаторы (фиксируют сустав и корпус) и синергисты (усиливают движение).
Чтобы прокачать стабилизаторы, например, надо выключить основные мышцы с использованием тренажера, чтобы основная нагрузка была именно на те мышцы, которые нам необходимо.
По аналогии для прокачки управленческой мышцы нам необходимо отключить нашу экспертизу.
Как это сделать?
Начать управлять командой, где у вас нет предметной экспертизы.
Так вы автоматически подключите управленческую мышцу, потому что по другому просто не получится достичь результата.
А возвращаясь уже на привычку позицию, ты вдруг понимаешь, что у тебя кроме сильной экспертизы теперь честь и другая действительно сильная экспертиза - управление.
Поэтому в Японии управленцы периодически меняли свои позиции - руководил маркетингом, стал управлять складом или производством.
Это тоже про концентрированно прокачать управленческие компетенции.
Я не предлагаю менять ТОПов местами, есть вариант лучше.
Можно стать OKR-мастером для команды, где у тебя нет экспертизы и помочь ей достичь крутых результатов.
А я пока предлагаю вам перейти в мой телеграм-канал и больше узнать об OKR и лидерстве.
Более 2000 лет назад Сократ придумал концепцию - быть -> делать ->иметь
Суть ее в том, чтобы что-то «иметь», нам необходимо в начале «быть» этим человеком или компанией, потом «делать» (совершать поступки из этого нового состояния) и в результате поступков мы будем иметь то, что хотели.
Прочитайте еще раз. Вызывает ли у вас это сопротивление?
Почему?
Мы же часто хотим в начале что-то иметь, а уже после думаем про все остальное.
Но как можно «быть» в самом начале — спросите вы?
«Я же сначала хочу иметь млн долларов, а уже после этого я могу стать богатым. Наоборот не получится».
Но на самом деле всё не совсем так. Люди, которые выиграли лотерею или в казино, не остаются богатыми надолго.
Как думаете, почему?
Чтобы чего-то достичь, важно внутренне стать/быть таким. Именно этот новый подход изменит ваш способ мышления. Оно изменит действия, и уже это с более высокой вероятностью обеспечит «иметь».
Давайте посмотрим на такую ситуацию:
Есть ли для вас разница между - быть «отцом» и иметь детей?
Для одних разницы не будет. Это нормально 🙂
Но другие скажут что разница огромна — можно иметь детей и не быть отцом, а можно быть отцом, не имея детей.
Быть отцом — это цель, сформированная формате бытия (состояния).
Иметь детей — цель в виде действия (изменения).
А при чем тут OKR?
Когда мы только формировали с Татьяна Винтерголлер первый курс по OKR 3 года назад, то отметили , что есть цели-состояния, а есть цели-изменения. И долго обсуждали, стоит ли так усложнять на курсе. В результате первого прогона отказались.
И только в этом году я понял, в чем их отличия.
Формируя цель в формате состояния (каким я/компания хочу быть?), вы создаете целый набор вариантов, какие для этого необходимы изменения (цели-изменения) и, таким образом, создаете для себя целое пространство вариантов.
Если же вы фокусируетесь на целях-изменениях, то часть вариантов можно упустить.
Что важно — выбирайте тот вариант, который для вас комфортен на данном этапе. Если вы формируете цели от изменений, вы уже получаете преимущество перед 95% других, в следующем году сможете сделать следующих шаг 🙂
А как вы формируете цели и какой подход ближе? Поделитесь в комментариях.
P.S. Это пост-пояснение к публикации “В поисках идеальной формулы OKR”.
В интернете можно найти чек-листы для проверки качества OKR — вдохновляющие, конкретные, измеримые.
Мне не нравится, что в этом случае форме уделяется больше внимания, чем содержанию. На практике все несколько по-другому: мало ценности бывает в переформировании цели из обычной в амбициозную, если это не продвигает команду.
Но вопрос остается: как выглядит идеальная формула OKR?
В определении Цели важно:
1. глагол;
2. объект изменений;
3. качество, которое приобретает объект в процессе изменений.
И что-то это мне все время напоминало, аж до зуда. 🤔
А ведь есть формула составления работ в JTBD - «глагол + существительное + контекст». Можно ли ее применить и тут?
Стал изучать, и оказалось еще интереснее:
Теорию JTBD активно разрабатывали 2 человека - Энтони Ульвик и Алан Клемент.
Ульвик говорил, что работа это « job-activities» - «do goals» - работы - действия (пример: построить дом).
А в это же время Клемент доказывал: работа — это что-то ценностное - «be goals» - работа как состояние или бытие (пример: быть хорошим отцом).
Много копий было в свое время сломано при обсуждении, какой подход лучше, а на самом деле они отлично дополняют друг друга по аналогии с целями-состояний и целями изменений.
Таким образом, для формулирования Objective можно использовать формулу «глагол + существительное + контекст качество» (прилагательное или изменение).
Ключевые результаты должны в полной мере описывать качество. Если качеств несколько, то для каждого должна быть своя метрика.
Например, вы сформулировали цель - «Стать умным, красивым и сильным», то для каждого качества нужная своя метрика :)
Вспомнилась фраза по итогу всей этой темы - бог один, провайдеры разные.
Попробуйте формулировать OKR в таком варианте и поделитесь результатам, плз :)
Чтобы достигать ДРУГИХ результатов нужно действовать по-другому, а в начале думать по-другому.
Новый результат ⬅️ новый способ действия ⬅️ новый способ мышления.
А для этого очень много нужно вкладываться в развитие команды и конкретных людей.
И вот тут есть проблема - 90% предпринимателей не хотят заниматься развитием команды.
Люди это сложно, долго и еще ненадежно. Только научишь, а они и уйти могут.
Вот бы как-то решить эту задачу, но чужими руками.
И мы научились это делать!
Когда мы запускаем OKR в компании, то обязательно вводим своих OKR-мастеров.
Их задача - научить команду действовать по-другому, максимально эффективно выстроив процесс достижения целей. А уже через достижение целей трансформировать мышление.
❗ В результате команда начинает кратно быстрее бежать (есть кейсы когда за 3 месяца получили результат больше, чем за предыдущие 9 месяцев). Также она забирает ответственность за достижение цели и изменения, которые для этого необходимо реализовать.
По итогу мы и получаем тех самых лидеров, которым нужна поддержка, а все остальное они могут и сами.
Лайфхаком является то, что при запуске OKR мы готовим в компании внутренних OKR-мастеров, которые начинают уже сами вести команды изменений дальше.
В рамках этой роли он работает с командой - 1-2 часа в неделю, что позволяет ему эффективно выполнять и свои основные функции.
При этом он помогает команде достигать целей, и прокачивает свою модель горизонтального лидерства. Это когда у тебя нет прямой власти над командой, но ее все равно нужно научиться направлять и даже управлять.
Вот и получается что мы получаем в 2 раза больше лидеров:
1. Те кто умеют достигать целей с командой.
2. Те кто умеют выстраивать процесс команды так, чтобы она достигала целей.
«Дай человеку рыбу, и он будет сыт один день. Научи человека ловить рыбу, и ты накормишь его на всю жизнь».
Когда разработчику пора к юристу: типы лицензий ПО, коварный open source и авторское право на код
В новом выпуске Sravni Podcast поговорили с Юлией Суворовой, Head of Legal and Compliance в Сравни. В том числе о проверке лицензий в случае с open source решениями, оформлении интеллектуальной собственности и других сценариях взаимодействия юристов с ИТ-командами.
Также в выпуске:
📌Всем ли ИТ-компаниям (и командам) нужны юристы; риски их отсутствия 📌Юридические кейсы в ИТ: покупка ПО, проверка open source библиотек, оформление права на код 📌Как нормативные акты влияют на процессы разработки 📌Юрист в ИТ: в чём специфика этой профессии?
Менеджер: насколько трудоёмко вернуть галерею на страницу товара? Сейчас мы принимаем только 1 картинку, а нужно несколько.
Разработчик: Просто взять и вернуть нельзя. Галерея была лет 5 назад, я даже не помню как она выглядела. Если надо - будем делать, не надо - не будем. Трудоемкость тут не причём, как мне кажется.
Менеджер: Ну бизнес измеряет все часами и днями....
Как думаете, в контексте этого диалога, имеет значение, как бизнес считает сроки? Или сроки здесь вообще не важны?
Моя позиция такая: если оценки сроков влияют на нужно/не нужно, то скорее всего не нужно.
Нужно/не нужно должно определятся целями. Нужно/не нужно сейчас - важностью. Нет целей - как понять важно это или нет?
Оценки сроков важны, спору нет, но они должны влиять на приоритет:
Если важная и её делать долго, то нужно начинать сейчас. Приоритет самый высокий.
Если важная, но делать быстро и дедлайн далеко, доделываем текущие и начинаем важную. Приоритет высокий, но ниже текущих.
Когда я говорю 2 дня, и менеджер говорит - делаем, а когда 2 недели - не делаем и забываем на полгода, тогда с оценкой нужности и важности задачи явно что-то не так.
Эта ситуация может быть показателем отсутствия целей и стратегии развития продукта.
А бывает еще так, что менеджер или руководитель начинает давить, что бы уменьшить сроки... сами подумайте - оно вам надо?
