Этот текст мы написали по интервью одного из наших клиентов. Он так вдохновился накопительной диаграммой потока, что решил рассказать о своём опыте нам. А мы — вам :-)
Как складывать трудозатраты по-новому. Когда хочется быть гибким, но привычные сторипойнты не решают проблему, а как будто только создают новую. Попробуем изобрести новый гибкий способ расчета трудозатрат, который, работает.
Устали от того, что 2SP+2SP ≠ 4SP? Не знаете, как объяснить, что у одной команды фича на M большемерит, а у другой команды фича на L маломерит и потому они займут примерно одинаковое время? Тогда вам сюда!
Я в IT очень давно и еще помню те времена, когда IT тусовка была практически камерной, многие друг друга знали лично и была просто профессия программист — это было почти как аникейщик — подразумевалось, что ты можешь писать практически на любых языках и можно было с бэкграудах в плюсах спокойно подаваться хоть на JAVA, хоть на 1С и возможно даже немного заниматься дизайном, версткой и сборкой компов.
Тогда мало кто думал о чистоте и поддерживаемости кода — в него по сути никто и не заглядывал, главное было рабобтает или нет, решает ли задачу заказчика. Ключевым требованием было «быстрая обучаемость», так как практически все отрасли в IT были в новинку. Было безумием пытаться искать специалистов с годами опыта, так как все отрасли только‑только появлились, да и выпускников по специальности IT практически не было, а если и было, то это были специалисты по Fortran и численнным методам. Практически все ITшники тогда были выпускниками физфака и матфака (а не пришли с завода за халявным смузи как сейчас).
Соответвенно в совсем новой области, процесс работы в которой был сложно контролируемым, по факту единственным возможным способом отбора был тест на интеллект и принадлежность «своей касте». Думаю, оттуда возникла традиция общаться на «ты» в IT — как некое пространство единомышленников.
Собственно поэтому и искали «просто» умных, настандартно мыслящих людей — в силу неоформленности рынка тестировалось как человек может решать странные, нестандартные задачи, а не тушеваться.
Для бизнеса такой подход хорош лишь в условиях сверхприбыли — ведь по факту у него возможности контроля сильно ограничены — а риски высоки, так как в те времена программист начинал приносить пользу только через пол‑года или год, когда полностью войдет в дела компании. HR сейчас любят повторять эти цифры, но сейчас это, разумеется, ложь.
Работая над статьёй ИИ не изменит IT, я обратила внимание, что ключ ко многим проблемам нейросетей — это закон Гудхарта: «Когда мера становится целью, она перестаёт быть хорошей мерой». Закон этот настолько универсальный, что захотелось посвятить ему отдельную статью.
Он объясняет, почему ChatGPT галлюцинирует, когда его поощряют за правдоподобность, школьники учатся списывать ради хороших оценок, а поисковики постоянно обновляют алгоритм ранжирования.
«Сделал и забыл» — это не про сайты, не про SEO и не про цифровой маркетинг. В этой статье разберёмся, почему это не чья-то злая воля, а системная закономерность. И как, понимая её, выстраивать устойчивые процессы.
Это не диагноз, а технический отчёт о состоянии системы под названием «Я-удалёнщик». Если вы работаете в таком же формате и мотивация иногда глючит — возможно, мы дебажим одну и ту же багу.
Когда хорошая идея становится популярной - все начинают пересказывать её "как поняли". В итоге в информационном поле от изначальной идеи остаётся настолько мало, что её перестают воспринимать всерьёз. В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП
И сразу отвечу на вопрос, зачем это вообще может понадобиться.
Есть четыре типовых ситуации:
1. Вы или проходите собеседование, или уже вышли на новую работу. Если собеседуетесь — то хорошо бы понять, насколько вы вообще готовы ввязаться в происходящее и чем оно может вам грозить. Если же уже вышли на работу — значит, в ближайший квартал от вас будут ждать какого-то результата, и вам надо не распыляться на все сразу, а найти точку приложения своих усилий, чтобы решить какую-нибудь проблему, показать результат и доказать руководителю свою ценность.
2. Участие в due diligence. Ваша компания планирует покупку стороннего бизнеса. Тут аудит нужен для того, чтобы не повестись сходу на красивые продающие слова и не купить кота в мешке. С большой вероятностью, техническая сторона при объединении бизнесов может оказаться в вашей зоне ответственности, и нужно понимать, чем это грозит.
3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.
4. Вы не собираетесь ни на новую работу, ни покупать чей-то бизнес — вам просто кажется, что у вас сейчас на работе что-то идёт не так, и вы хотите всё оценить и понять, что именно.
В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.
Всем привет! Меня зовут Марина Гончарова, и я IT-проджект-менеджер в Купере.
На моем проджект-веку было много разных компаний, разных продуктов, и весь этот опыт можно разделить на две большие категории. Первая — классика: я нахожусь внутри продуктовой команды, управляю бэклогом, распределяю загрузку, руковожу процессами разработки. Вторая: своей команды у меня нет, но есть проекты, которые нужно оценить, спланировать по бюджету, выполнить и запустить в срок.
Именно во второй роли я сейчас работаю в Купере. Легко ли это? Нет, но безумно интересно и драйвово!
В пандемию моя команда из Москвы и Казани переходит на удаленку. Нет больше привычных смолл-токов у кулера, не слышно шума офисной жизни. Даже после снятия ограничений и возможности вернуться в офис, команда остается на удаленке, а география, наоборот, расширяется — теперь к нам присоединились ребята из Питера, Москвы, Калуги, Костромы, Рязани, Казани и Томска. Встречи традиционного ретро перешли в онлайн-формат.
В этой статье расскажу, как превратить ретроспективу в яркое событие, в котором каждый участник может снять стресс, проявить себя и получить положительные эмоции. Посмотрим, как работает каждый этап ретро с точки зрения сплочения команды на примере доски «Вокруг света за одну ретроспективу».
Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.
Привет! Сегодня расскажу про Discovery-процесс в команде.
Discovery и Delivery процессы разделены. В Discovery-команду могут входить продакт-лид, продакт-менеджеры, продакт-аналитики, бизнес-аналитики и UX-дизайнеры/проектировщики. Если же задачи технические, то подключаются тех/тим-лиды, архитекторы и другие технические специалисты.
Что такое Disco? Discovery в первую очередь отвечает на вопросы и «Что делать?» и «Надо ли вообще делать?». Delivery - «Как делать?».
Discovery-команда занимается обоснованием и проработкой инициатив, которые затем попадают в продуктовый бэклог для последующей реализации в Delivery.
Для запуска с нуля такой команды и их процессов мы используем следующий чек-лист:
Жёсткость неустойчива. Жёсткие процессы, фреймворки и механизмы управления проектами могут давать краткосрочные результаты, но подрывают долгосрочную устойчивость.
Для менеджеров, которые долгое время подчинялись одному и тому же руководителю или работали в организации с чётко определёнными целями, легко незаметно развить пробелы в навыках. Обычно это происходит потому, что в той среде, где вы профессионально выросли, эти навыки просто не были особенно важны. В итоге вы можете стать очень уверенным в своих текущих умениях, перейти в новую организацию, где требуется другой набор компетенций, — и внезапно потерпеть неудачу.
Существует несколько распространённых сценариев, но тот, о котором я хочу поговорить, касается ситуации, когда менеджеры формируются в организациях с жёстким централизованным планированием («роли, основанные на координации»), а затем оказываются на достаточно высокой позиции или в компании с организацией “снизу вверх”, где от них ожидают не координации, а именно лидерства («роли, основанные на лидерстве»).
Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.
Главная мысль статьи: Не подстраивайте Scrum под старую структуру компании. Меняйте структуру компании, используя Scrum как инструмент трансформации. Делайте это постепенно, маленькими шагами, постоянно учась и адаптируясь.
Статья является вольным переводом «Re.Imagine Your Scrum Firm up Your Agility» Гюнтера Верхейена.
Всем привет! Мы сотрудники отдела внедрения мультиязычных систем и сервисов из IT-компании SM Lab: отвечаем за обучение пользователей работе с информационными системами (ИС) группы компаний «Спортмастер». Проще говоря, мы те самые люди, которые находятся между разработчиками, выкатывающими новый функционал, и пользователями, которым с этим функционалом предстоит работать. Обучаем не только сотрудников офисов и магазинов, но и иностранных партнёров ГК «Спортмастер».
Наша главная цель — помогать людям адаптироваться к новым системам и интерфейсам, будь то продавец Иван из Екатеринбурга или мистер Ли, упаковщик кроссовок на фабрике в Китае. Мы делаем всё, чтобы пользователи не терялись в новом интерфейсе, работали без проблем и ошибок, и всегда знали, на какую кнопку нужно нажать.
Всем привет! Меня зовут Амина Шарифьянова, и сегодня я хочу поделиться опытом трансформации, которая изменила не только подход к работе в нашей команде, но и в целом — наше мышление, отношения внутри команды и взаимодействие с бизнесом.
Сейчас agile-практиками никого не удивишь, все уже давно прочитали практическое руководство (или вы еще нет?:) ) и стремятся выполнять по методичке привычные функции: планировать, разрабатывать, тестировать и далее по циклу. «Но ведь все это мы делали всегда, зачем нам agile?» — с таким возражением пришлось работать больше всего, ведь сроки учитывались и раньше, ценность все понимают и так… При этом, меня не покидало тимлидское чувство что «что‑то не так», разобралась в этом для себя и делюсь с вами.
Гильдия VS воскресный приход: сообщество экспертов, которое решает, а не только играет в Манчкина
Привет! Написал статью про корпоративные гильдии и их дисфункции, потому что уж очень часто с ними и в них работаю. На текущем месте работы есть гильдии, профессиональные сообщества, рабочие группы и центры компетенций с центрами практик. Их задачи и зоны ответственности сильно пересекаются, что создает много сложностей. В общем, наболело.
Долгое время принцип «предела компетентности», сформулированный Джоном Питером, был шуткой-«внутряком» менеджмента всех уровней. При этом актуальность принципа не ставилась под сомнение профессионалами менеджмента, с которыми мне доводилось сталкиваться по жизни. И место этой шутки было примерно там же, где и «обезьянки-ответственность», скидываемые сотрудниками на плечи своих руководителей по всему миру. Но в последнее время острота явления, которое мы назвали «принципом Питера», стала очевидно заметнее.
Да и концепция давно получила подтверждение, есть очень интересные современные исследования (MIT 2018, Placci 2019, Banca d'Italia 2022).
Формулировка принципа звучит так:
«В иерархической системе каждый работник поднимается до уровня своей некомпетентности».
Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор».
Попытки внедрить новые практики, такие как Scrum или Kanban, часто наталкиваются на сопротивление команды, которой комфортно работать в существующем workflow. Иногда проблема усиливается часто меняющимися менеджерами, каждый из которых приносит «волшебную таблетку», оставляя после себя след из никому не понятных артефактов. В результате процессы внедряются поверхностно, лишь создавая видимость изменений. Команда двигает тикеты на Kanban‑доске — значит, у нас «Kanban». Проводятся спринты — значит, у нас «Scrum». Но настоящей ценности такие формальные преобразования не приносят.
