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

Всех с новым 2024 годом. Сегодня история "пятничная", развлекательно-познавательная. Произошла она с нами в середине осени 2023 года. Мы уже третий год разрабатывали продукты для нашего мини-бизнеса. Команда насчитывала 5 человек, в том числе Максим, наш бэкэнд-программист, который в том числе и создавал код для наших телеграм ботов. Умный, казалось бы, парень, который больше года назад присоединился к нам. В какой-то момент для мотивации я предложил ему платить процент от прибыли компании за поддержание проектов и дополнительно платил за новые разработки. За год мы выросли в несколько раз, так что все казалось бы все должны быть довольны и никто не думал о безопасности, но что-то пошло не так...

В один "прекрасный" день я получаю от Максима сообщение, общий смысл которого такой:

Я решил выйти из проекта, так что перенёс весь код и базы данных на свой сервер неделю назад, так что бэкапов у вас тоже нет. За 800 000 рублей верну всё назад.

Продолжение, а так же ошибки, что мы допустили и решения, что мы внедрили читайте в под катом...

По мере того как И.И. все больше проникает в общественное сознание, мы начинаем видеть антиутопические истории о будущем работы, предсказывающие своего рода окончательную победу макиавеллиевских сил капитализма.

Самый яркий пример - автор научной фантастики Тед Чианг, который недавно задался вопросом, есть ли "способ для И.И. сделать что-то еще, кроме как точить лезвие ножа капитализма?". По данным Insider, сотрудники JPMorgan, возможно, уже страдают от такой динамики благодаря мощным инструментам мониторинга сотрудников компании.

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

За многие годы моей карьеры я столкнулся с множеством вызовов и уникальных ситуаций, которые позволили мне глубоко погрузиться в мир гибкого управления проектами. Думаю, статья будет полезна РМ’ам всех уровней.

В целом, эти методологии и инструменты – это более чем просто методы управления проектами; они представляют собой стратегии выживания и процветания в мире, где изменения – это новая норма.

Гибкость в управлении проектами – это способность адаптироваться к меняющимся условиям и требованиям без потери эффективности. Использование правильных инструментов и техник может значительно улучшить адаптивность команд и проектов.

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

Я работаю тимлидом и лидом лидов на разных уровнях в разных по масштабу командах разработки уже более пяти лет. За это время я прошел несколько стадий развития - от взгляда "тимлид - это просто самый опытный разработчик" до стадии, когда мне нужно регулярно растить или нанимать тимлидов в разные команды. На последнем этапе я столкнулся с тем, что мне нужно найти тимлидов сразу в несколько новых команд, которые появились после реорганизации направления разработки в компании. 

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

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

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

В этом посте я начну с самых основ - поделюсь как я выстраиваю коммуникацию с каждым отдельным участником команды. Если пост получит хороший отклик - постараюсь раскрыть и другие темы.

Привет! Я Виталий Дощенко, New Business директор в AGIMA. Поговорим о моделях работы с заказчиком. Вот статистика по нашим контрактам: 52% — Time and Materials, остальные — Fixed Price. Хотя перевес в сторону T&M, я объясню на простом примере, почему для запуска новых проектов иногда лучше выбрать Fixed Price.

Машинное обучение (ML) в сфере анализа безопасности приложений SAST (Static Application Security Testing) — это область, которая с каждым годом становится все более актуальной в мире разработки ПО. Многие компании активно исследуют ее, а некоторые уже внедряют машинное обучение в продукты для анализа кода. УЦСБ разрабатывает собственную платформу по непрерывному анализу защищенности приложений и занимается внедрением моделей машинного обучения в качестве рекомендательной системы при поиске и верификации проблем безопасности. В серии статей, посвященной этой теме, планируем рассказать о потенциале внедрения машинного обучения в инструменты SAST и пошагово разработать модель анализа кода.

Привет, Хабр! На связи Пиробайт. В этом году мы разработали новую версию сайта для федеральной службы доставки «Гриль №1». У себя рассказали, как круто справились с задачей, но не упомянули о том, что приключилось на бэкенде. Считаем, что и такие стороны лучше освещать, мы за прозрачность. В статье расскажем, в чем была загвоздка с iiko (айко) и какие решения мы нашли.

Что больше злит: когда перенаправляют от одного к коллеги к другому и все равно не получаешь информацию, или когда постоянно меняются бизнес-требования? Мой текст посвящен работе над проектом в корпорации, вернее, решению главной ее сложности — коммуникации.

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

Меня зовут Мария Болдырева — я руководитель проектов в IT-компании Outlines Tech. В профессии 3,5 года, сейчас развиваю финтех-направления корпораций. Всего в управлении командами 6 лет. 

Опенсурс как таковой зародился, по сути, из культуры хакеров 80-ых. Они писали программы и обменивались ими друг с другом. Но эта идиллия не могла длиться вечно. В какой-то момент разработка ПО коммерциализировалась. Корпорации начали пользоваться открытым ПО, ничего не давая его разработчикам взамен, зато часто требуя от них фикса багов и добавления фич. Недавно тут обсуждали монетизацию опенсурса. Люди много чего писали, но по итогу не изобрели рабочего и непротиворечивого способа получать деньги за открытый код. Так почему же челы, чьи технологии использует огромное количество коммерческих фирм, по итогу сидят без денег?

Меня зовут Рустам Нурдавлятов, я являюсь руководителем одного из центров разработки в Nexign. В этой статье опишем кейс создания HRM-системы, расскажем о схеме совместной работы команд HR и разработки, а также на собственном примере разберем продуктовый подход к созданию HR-систем. 

Многие считают 1С особым замкнутым миром. А методы работы в нем — неприменимыми в «нормальном» программировании. Это давно не так. Конечно, у каждого решения есть свои плюсы и минусы. Но я уверен: если вы не любите 1С, то вы просто не умеете его готовить. 

Меня зовут Владимир Короткий, я руководитель отдела проектов 1С в Lamoda Tech. В этой статье расскажу, по каким принципам мы работаем внутри компании и почему оптимистично смотрим в будущее этой технологии.

В Lamoda Tech на 1С завязана часть ключевых процессов, и количество систем на стеке 1С год от года только растет, — а все потому, что мы умеем и любим с ней работать. 

Рассказываю наши рецепты.

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”. Мы разрабатываем ИТ-решения для Петровича, крупного федерального ретейлера в сегменте DIY и строительных товаров.

За последние несколько лет компания существенно выросла (в продажах – в 10 раз за 10 лет, до 119 миллиардов рублей без НДС в 2022). Требования к надежности и стабильности ИТ — росли соответственно. 

Наверное, каждый из вас сталкивался с ситуацией, когда ИТ-сервис был недоступен в самый неподходящий момент. Чтобы не ходить далеко за примерами: такое случается даже с распространенными коробочными решениями уровня “практически индустриальный стандарт”, вроде JIRA или Confluence. 

Когда такое происходит, бывает соблазн подумать мысли из серии «ну чего там сложного-то, просто поддерживайте сервера включенными». Для бизнеса практически любой ИТ-процесс может выглядеть примерно так же — какой-то черный ящик, который то работает, то нет.

Мы понимаем, что могут быть сотни факторов, из-за которых все идет не по плану — и в разработке, и в сопровождении ИТ-сервисов. Чтобы бизнес тоже это понимал и строил планы с учетом этого знания — нужен некоторый общий контекст, договоренности об уровне услуг. Если согласовать подобные вещи, выиграть могут все: коллегам из бизнеса будет понятнее, что происходит; людям из ИТ – спокойнее за принятые на себя обязательства.

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

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

Цель бизнеса как известно - прибыль. Тут можно поспорить по части определения терминов, но сути это не меняет: цель бизнеса - деньги и как можно в большем количестве! как этого добиться? Логично: что необходимо увеличить прибыль и сократить затраты. Следовательно, одно из направлений этого - сокращение затрат. Как можно сократить затраты? Если не брать в расчет «стандартной процедуры» большинства руководителей как то: сокращение персонала и зарплат, то необходимо провести довольно большую работу по оптимизации бизнес-процессов (далее БП) с целью поиска «узких мест» и их ликвидации.

Привет, Habr! Меня зовут Руслан Габдрахманов, я руководитель команды разработки информационных систем в «МосТрансПроекте». Сегодня расскажу, как мы создавали городской сервис «Узнай про ЖК», упрощающий выбор квартиры или жилья. 

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

7. Советуйте «быть аккуратными». Будьте «разумны» и подталкивайте других участников совещаний к «разумности», к тому, чтобы они избегали спешки, которая может в будущем вызвать неудобства или сложности.

8. Беспокойтесь о правильности каждого решения, поднимайте вопрос о том, будет ли рассматриваемое действие относиться к юрисдикции группы или оно может вызвать конфликт с политикой какого-то более высокого эшелона.

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

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

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

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

Привет! Я Наташа Тарасова, руководитель проектного офиса в AGIMA. Сегодня хочу поговорить об одном из самых важных качеств в заказной разработке — умении прогнозировать. Иначе сказать — попадать в ожидания, и в первую очередь, в свои собственные. Будет полезно всем проектным менеджерам и их руководителям. 

Добрый день. Меня зовут Тимофей, я фронт-тимлид в диджитал-продакшене ДАЛЕЕ. В данном цикле статей я поделюсь подходами и инструментами фронтенд-разработки на аутсорсе, которые помогут создать качественный продукт без кошмарного instant-legacy и значительно облегчат жизнь команде разработчиков и не только.

Расскажу, почему не стоит излишне усложнять архитектуру фронтенда, и дам примеры удобных и эффективных инструментов разработки с точки зрения DX (developer experience. Это важно) и дальнейшей поддержки.

Привет, Хабр! Меня зовут Денис Фурсенко, в Росбанке мы в команде с Владиславом Смеловским развиваем процессы непроизводственных сред, работу с дефектами на них, разворачиваем дополнительный интеграционный контур банка, а также координируем развитие интеграционных поставок. В этом посте я расскажу, как устроены циклы поставок у нас в банке — в частности, интеграционные поставки. Остановлюсь на том, как мы выявляем причины инцидентов после поставок, поделюсь лайфхаками и расскажу, как менеджеры поставки могут повлиять на качество поставок.