Управление разработкой *

Теория ограничений (ТОС) — это управленческая методология, предложенная Элияху Голдраттом в 1984 году в его книге «Цель». Она базируется на простом, но мощном принципе: любая система, будь то производство, бизнес‑процесс или команда разработки, всегда ограничена одним или несколькими узкими местами. Эти ограничения или «бутылочные горлышки» сдерживают общую эффективность системы и являются теми ключевыми элементами, которые необходимо обнаружить и устранить для значительных улучшений.

В условиях разработки продуктов, где скорость поставки, качество и удовлетворение клиентов критически важны, применение теории ограничений может привести к существенным улучшениям процессов и результатов. Давайте рассмотрим, как ТОС работает на практике и каким образом она может помочь командам разработки.

Привет! Меня зовут Иннокентий Корнилов, я ведущий инженер‑разработчик в Bercut, где работаю с 2013 года.

Развиваю и поддерживаю систему «Автосборка», которая берет начало в 2007 году. Это система управления конфигурациями, автоматизирующая процессы сборки, версионирования и выпуска релизов; ключевой инструмент, который обеспечивает единообразие разработки и выпуска программного обеспечения в нашей компании. Благодаря «Автосборке» мы можем управлять процессом сборки компонентов и систем, поддерживать версионность и статус готовности продуктов, а также обеспечивать их корректную доставку заказчикам.

Статья посвящена истории преодоления технических сложностей, возникших на различных этапах проекта, и описанию ключевых моментов, которые определили наш подход к работе над системой.

Меня пригласили как эксперта по внедрению гибких подходов управления в одну IT-компанию, занимающуюся разработкой решений в сфере B2B. Основная задача заключалась в том, чтобы настроить процессы управления проектами, сделать их предсказуемыми и управляемыми. До начала сотрудничества компания сталкивалась с множеством проблем: сроки регулярно срывались, клиенты были недовольны, проекты могли «висеть» в работе до 8 месяцев без завершения, а команда испытывала серьезные перегрузки из‑за параллельной работы над несколькими задачами.

Всё это приводило к недовольству как внутри команды, так и среди клиентов, которые часто получали ложные обещания по срокам. Основной задачей было создать предсказуемый процесс, который позволял бы компании не давать ложных обещаний заказчикам и завершать проекты вовремя. Мы начали с внедрения kanban метода, который позволял быстро внести изменения в работу компании и сделать процесс более управляемым.

Я описал свой путь в предыдущей статье https://habr.com/ru/articles/813239/, но если коротко, то моя карьера в сфере информационной безопасности началась, как и у многих, с работы в ИТ-инфраструктуре. Поначалу моя компания занималась тем, что поддерживала стабильность сетей и систем для различных компаний, и регулярно сталкиваясь с типичными проблемами, связанными с кибератаками. Однажды в компании, где штат ИБ был минимален, мы внедрили SIEM — решение, которое, как считалось, должно было кардинально улучшить безопасность. Однако это был дорогостоящий и трудоёмкий процесс. SIEM не только не оправдал ожиданий, но и породил кучу инцидентов, большинство из которых не представляли реальной угрозы. Специалисты тратили время на анализ множества событий, которые, по сути, были незначительными. С каждым новым ложным срабатыванием доверие к системе падало. В конце концов, люди просто начали игнорировать предупреждения, считая, что система безопасна, хотя это было далеко не так.

Так я сформулировал ключевую проблему SIEM:
В обычных организациях, где число специалистов по ИБ ограничено, использование SIEM часто не приводит к ожидаемым результатам. И именно это открыло мне глаза на необходимость поиска нового подхода. Я начал думать о том, как можно было бы автоматизировать процессы безопасности, не нагружая команду ложными тревогами и сложными настройками.

Как пояснить разницу между грейдами разраба (джун/мидл/сениор) простыми словами? На выходных катался с детьми на велосипеде и понял, что один из них велосипедист-джун, а второй хороший такой мидл.

Это натолкнуло меня на очередную классификацию этих грейдов через аналогию через обучение детей ездить на велосипедах.

Вы думаете, мы в ИТ сидим и из воздуха берем цены для закупок? Конечно, нет. Каждая цифра в смете — это не фантазия, а отражение реальных затрат и рисков.

Для начала давайте посмотрим, почему цены на ИТ-услуги растут в целом?

Привет! Меня зовут Кермен, я — аналитик на второй линии SOC. Наша команда исследует данные от инфраструктуры и сервисов Ozon для выявления нелегитимной активности: от нарушения политик информационной безопасности до целенаправленных атак.

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

Иногда информации в событиях нам недостаточно, поэтому мы обогащаем их дополнительными признаками с помощью вспомогательных объектов: таблиц, макросов, моделей машинного обучения.

Нам захотелось навести порядок, поэтому позаимствовали опыт разработчиков: сделали новый формат хранения, добавили больше метаинформации, настроили CI/CD, и теперь у наших объектов есть свой жизненный цикл, включающий в себя этапы разработки, тестирования, перенос в продакшн, пересмотр и отключение.

Для этого на свет появился фреймворк для разработки и управления контентом — catzone или, как его чаще называют, котозон. В статье расскажу, как мы к нему пришли, из чего он состоит и как сейчас упрощает нашу жизнь.

Ещё до ухода Microsoft менеджеры проектов часто переключались между двумя системами — Project использовали для планирования задач и, например, Jira для их исполнения. В этом случае они вручную или с помощью дополнительных плагинов синхронизировали данные, а также отдельно узнавали статусы у исполнителей в третьем решении или мессенджере.

При этом Project оставался самой популярной системой для ведения проектов в крупных компаниях. Мы с командой понимали, что рано или поздно Microsoft отключит российских пользователей, поэтому заранее стали готовиться к росту запросов на «полный аналог» и перепридумали своё проектное управление. 

Меня зовут Максим Тимонов, я дизайн-директор в «Первой Форме». В этой статье я покажу, какие возможности мы добавили, чтобы заменить MS Project и объединить всю проектную работу в одной системе. 

Трансформация программного продукта — это не просто доработка или исправление, а полное обновление системы, включающее архитектуру, код и пользовательский интерфейс. Она необходима, когда технологии устарели, продукт не масштабируется, не соответствует требованиям бизнеса или вызывает жалобы пользователей. Важно вовремя распознать признаки необходимости изменений, чтобы избежать больших затрат в будущем. Однако часто различные подразделения не видят общей картины, что замедляет процесс осознания необходимости трансформации.

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

Привет, меня зовут Никита, я — продуктовый дизайнер в Effective Technologies. На работе ищу и внедряю наиболее эффективные способы решения проблем бизнеса и пользователей, учитывая технические ограничения и имеющиеся ресурсы. В итеративном улучшении продуктов компании мне помогают CustDev, UX-тесты и исследования, валидация метрик. А ещё я занимаюсь социологией, тема моей кандидатской — трудовая мотивация. О ней мы и поговорим в этой статье. Как Agile влияет на мотивацию сотрудников? Спойлер: положительно, но при определённых условиях. Я остановлюсь на каждом из них и подкреплю свои выводы научными данными.

На шкале стресса Рея и Холмса увольнение занимает восьмое место среди 43 наиболее стрессовых событий жизненного пути. Это тревожное событие как для сотрудника, так и для руководителя: мир IT тесен, и нужно понимать, что в какой-то момент вы можете встретиться снова, чтобы вместе работать. Так как поступить правильно и где всё-таки поставить запятую в «Уволить нельзя оставить»?

В любой продуктовой компании с Agile-подходом существует множество вызовов, связанных с управлением потоком идей и задач. Когда нет четкой системы отбора идей и приоритизации, команды могут столкнуться с дублированием работы, перегрузкой и хаосом в процессе разработки. Это приводит к тому, что новые идеи попадают в команду спонтанно, без достаточной проработки и согласованности между стейкхолдерами, что в итоге влияет на то, что делается много работы, которая не приносит должного эффекта.

Все руководители проектов слышали словосочетание «управление рисками». Если спросить на собеседовании, что такое риски и как ими управлять, видно, что РП усердно вспоминают определение риска, вспоминают слово «митигация», но вот ответить на вопрос о том, как с этим работать, не может почти никто. В тоже время есть много книг, посвященных управлению рисками в проектах, на Хабре есть несколько интересных статей (я гуглил, пока готовился).

Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?

Давайте разберемся с рисками.

Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 25 лет опыта в ИТ. Если вам такой опыт интересен, читайте другие мои статьи здесь на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Недавно я столкнулась с испытанием, которое, хотя и было непростым в тот момент, стало значимым моментом в моей карьере.

Мне доверили руководство новой командой в проекте, который уже был в стадии разработки. Эта команда работала по процессам, отличающимся от стандартных практик нашей компании. Веря в их экспертность и не желая разрушить устоявшийся рабочий процесс в бегущем проекте, я решила не углубляться особо в их методологию и не проводить дополнительных встреч, чтобы выяснить детали: как они работают, как проект работает и как именно планируется реализовать задуманное решение. Я безоговорочно доверилась их прогнозам по срокам — это то, что впоследствии оказалось моей главной ошибкой.

За две недели до дедлайна я провела мит с использованием чек‑листа, который подготовила заранее. К моему разочарованию, бОльшая часть работы была не завершена, а то, что было сделано, не соответствовало ожиданиям. Мы существенно отставали от графика, и качество оставляло желать лучшего.

Вместо того чтобы искать виноватых, я собрала команду для откровенного обсуждения. Я подчеркнула важность проекта для компании и возможные последствия, если мы не уложимся в срок. Объединенные общей целью, мы разработали план по возвращению работ в график, где я уже точно знала кто, что и в какие сроки планирует сделать, а так же результаты, которые должны быть получены на каждом промежуточном шаге. Работа закипела, часто по 16+ часов в день. Все это время я была рядом с командой: доставала технические и человеческие ресурсы, помогала проверить решения, организовывала встречи и просто старалась поддержать, когда казалось, что уже ничего не получится. Я также запросил продление дедлайна на одну неделю в качестве исключения.

Современные компании стремятся повысить оперативность и гибкость в управлении ИТ‑услугами, чтобы быстрее реагировать на запросы бизнеса и улучшать клиентский опыт. Традиционные подходы ITSM (управление ИТ‑услугами) с их жесткими процессами и бюрократическими барьерами часто не справляются с этими задачами. Работа по Agile позволяет трансформировать управление ИТ‑услугами, делая его более эффективным и адаптивным.

Это все ещё вопрос?

Возможен ли современный чип-дизайн без использования покупных IP-блоков – взгляд директора дизайн-центра.

Вот уже несколько лет на совершенно разных площадках разгораются холивары о том, что пора бы прекращать использование в отечественном чип-дизайне иностранных IP-блоков. Как-то следовало бы сделать свои персональные, ну или, на худой конец, отечественные, использовать только их, давать баллы отечественности за площадь кристалла, занятую своими IP и т.д.

Будучи частым участником таких вот дискуссий, я решил высказаться на данную тему.

Сразу скажу, что статья не претендует на инженерную точность, является частным, субъективным и предвзятым мнением автора. Вопрос наличия «закладок» тоже рассмотрен тут не будет.

Для начала немного терминологии.

Привет, Хабр!

Меня зовут Егор Прокопьев, и я фронтенд-разработчик в Ozon.

Третья версия полюбившегося многими фреймворка Vue вышла уже давно, и большинство использующих его произвели обновление до новой версии. Но всегда будут такие, как наша команда, кто откладывал этот переход в дальний ящик техдолга — ведь есть более приоритетные задачи! Однако рано или поздно этот день настаёт, и вот и для нас он пришёл.

В этой статье я хочу рассказать, как мы переходили на новую версию при том, что сервис является достаточно большим и очень важным для пользователей. Но обо всём по порядку.

Всем привет!

На связи команда Data Science компании ITFB Group. У нашей компании есть собственная разработка ITFB EasyDoc — система распознавания и извлечения данных из любого типа документов. В современном мире автоматизация обработки документов стала неотъемлемой частью множества бизнес-процессов. Предобработка изображений документов является важным шагом для обеспечения точности и надежности дальнейшего распознавания атрибутов. В этой статье мы хотим рассказать о некоторых эффективных методах предпроцессинга документов, позволяющих увеличивать как качество OCR-систем (Optical Character Recognition), так и различные CV и NLP пайплайны. Всем, кому интересна эта тема, — добро пожаловать под кат.