Проектный офис ответственен за множество инициатив, но команды сталкиваются с неясными требованиями, путаницей и постоянными изменениями. Знакомо? Для многих организаций это настоящая головная боль, которая мешает эффективно работать.
Ручная обработка заявок на обслуживание — это вечные звонки, потерянные письма и бесконечные уточнения. Особенно в крупных компаниях, где сотрудникам ежедневно нужна помощь ИТ-поддержки и хозяйственной службы. Поэтому сегодня в блоге ЛАНИТ на Хабр поделимся, как мы разрабатывали систему, которая облегчила работу канцелярии, с какими вызовами столкнулись и каких результатов удалось достичь.
Всем привет! Меня зовут Алексей Цыбульник, я помогаю внедрять Kanban в командах ПСБ. В банке я работаю с 2019 года, а вообще в IT больше 15 лет. Почти все это время всеми силами я продвигаю Kanban — учу методологии, веду подкаст, делаю конференцию о нем. Если вы интересуетесь этим миром, то можете меня знать :-)
В этой статье расскажу про системный подход, с которым будет проще самостоятельно внедрять Kanban в команде. Имя ему STATIK — System Thinking Approach To Introducing Kanban. Разберемся, чем он полезен и как ложится на принципы канбана.
Привет! Как и обещал, вторая часть доклада про то, как проводить быстрый аудит разработки без изучения кода (первая тут). Так как весь аудит по своей сути — это качественно поговорить и позадавать нужные вопросы, чтобы потом сделать выводы, то поговорить стоит и про более низкоуровневые вещи, такие как трекер задач, количество багов, метрики, используемые командой, и процесс разработки. В привычном по предыдущей статье формату «Хорошо / Плохо».
Метрики
Количество клиентских багов
Помните фильмы, где главный герой лежит в больнице, подключенный к кардиомонитору, и там на экранчике бежит график сердцебиений? Когда график вытягивается в прямую линию, значит, всё грустно и главный герой умер.
Так вот, с клиентскими багами такая же история. Это пульс продукта. Если в метриках их ноль — то это самое страшное. Это значит, что продукт или вообще не используется, или что клиенты никогда не запускали его.
Нет, конечно, есть исключения, когда какой-то продукт присутствует в компании чисто для галочки. Такое может попадаться в сфере информационной безопасности — например, клиент с точки зрения закона обязан купить какое-то ПО, но никто не будет проверять, используется этот софт на самом деле или нет. Скажем, купила компания антивирус, чтобы соответствовать требованиям регулятора, и просто положила его на полку — aka «бумажная безопасность». При таком подходе вообще без разницы, что там делает разработка — можно ее хоть уволить всю. Захочется ли вам работать в такой компании — это уже отдельный вопрос.
Итак, отсутствие багов — это плохо. Хорошо — это когда они есть, причем динамика изменений может быть любой, главное, чтобы это имело под собой какое-то логическое объяснение.
Мы часто слышим: «Agile умирает». На практике же проблема не в Agile, а в том, как его применяют. Там, где он превращается в набор ритуалов, команды тратят больше времени на согласования и отчеты, чем на сам продукт.
В этой статье — о процессах, которые реально помогают продуктовым командам доставлять ценность. Всё, о чём пойдет речь, — это личный взгляд, сформированный на реальных кейсах, ошибках и результатах.
«Казалось бы, всё просто: задачи ставятся, дедлайны есть, отчёты сдаются. Но почему через полгода никто не понимает, что реально работает?»
Маркетинговые отделы — одна из самых перегруженных и слабо структурированных зон внутри компании. Здесь сходятся креатив, данные, срочные задачи от руководства, подрядчики, рекламные бюджеты, неопределённые цели и «давайте вчера».
В результате даже сильные специалисты оказываются в бесконечном круге: правки, дедлайны, срывы, уставшие команды и нулевое ощущение прогресса.
Почему так происходит — и как это исправить системно?
Этот текст мы написали по интервью одного из наших клиентов. Он так вдохновился накопительной диаграммой потока, что решил рассказать о своём опыте нам. А мы — вам :-)
Как складывать трудозатраты по-новому. Когда хочется быть гибким, но привычные сторипойнты не решают проблему, а как будто только создают новую. Попробуем изобрести новый гибкий способ расчета трудозатрат, который, работает.
Устали от того, что 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.
