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

R&D или отдел Research and Development — это специальный отдел в компании который отвечает из слова Research, за то:

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

Звучит отлично – в теории.

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

Когда-то так было и у нас. Сейчас – все 30 участников высказываются по очереди, формируют рабочие группы по внедрению улучшений, разносят итоги встреч по своим командам.

За 2.5 года мы прошли путь от “лиды молча послушали рассказ о том, как космические корабли бороздят просторы большой стратегии” до “ребята сами придумали и реализовали точки роста, которые помогли компании сэкономить миллионы рублей”. 

Как развивался формат общих встреч лидов в Сравни – читайте в этой статье. 

Нам оставили немало комментариев к статьям по подготовке к собеседованию системного аналитика (СА) о том, что примеры со сложными вопросами по SQL, REST и диаграммам — избыточны. И что СА не обязан знать, как написать код обработки запроса на Python, И даже СУБД — тоже не сфера знаний СА, как и много другое. А что же обязан знать и уметь СА? Давайте пройдемся по новому профессиональному стандарту «Системный аналитик» от Минтруда РФ и возьмем требования для грейда «джуниор СА». Вам откроется немало удивительного. Правда, есть пункт, не вызывающий сомнений: «Русский язык в объеме, необходимом для выполнения трудовой функции».

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

Часто предприниматели считают делегирование небесной маной. «Как только все процессы и задачи будут переданы команде, я «выпрыгну» из гребаной операционки, уеду в Тай и буду дистанционно управлять компанией». 

В этих мечтах нет ничего зазорного.

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

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

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

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

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Привет, я Михаил Емельянов, руководитель Android-направления в RuStore. Над стором трудится большая команда разработчиков, проект регулярно дорабатывается, а количество новых строк кода неизменно увеличивается. 

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

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

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

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

Привет, я Юля Зубова — руководитель отдела аналитики в диджитал-агентстве ДАЛЕЕ. Хотя написано много статей про роль аналитиков, открыты сотни вакансий и есть даже целые сформированные отделы, остались компании и команды, где их нет. Иногда приходится объяснять, зачем нужны эти специалисты.

Расскажу, какую роль играет аналитик, на каких проектах он жизненно необходим, а на каких можно обойтись и без него.

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

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

Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное.

Рефлексия о настоящей цели разработки программного обеспечения и о том, почему мы так часто об этой цели забываем.

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

14 лет я работал в международной компании Airbus – компании, занимающейся авиастроением. В IT же мой путь начался совсем недавно – всего лишь чуть больше года назад.

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

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

В этой статье мы исследуем эффективные практики для разработчика, отправляющего свой код на ревью. Эти практики не только упростят жизнь ревьюеру, но и помогут извлечь максимальную пользу из этого опыта и значительно сократят time‑to‑market.

Мы не будем углубляться в важность код‑ревью для команды и проекта. Сосредоточимся на практиках для разработчика, проходящего код‑ревью.

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

Привет, Хабр! Мы в компании Friflex запустили подкаст «Гости из IT». Вместе с ведущим Антоном Комоловым и экспертами из разных областей IT разбираемся в технологиях и изучаем, как они меняют нашу жизнь и работу. 

Сегодня делимся мыслями о профессии архитектора программного обеспечения: чем он занимается, какие инструменты использует и нужно ли ему уметь писать код.

Рассуждают Петр Щербаков, ведущий архитектор решений X5Tech, и Михаил Майоров, технический директор маркетплейса услуг YouDo.

Привет, Хабр! На связи Пиробайт — продуктовые разработчики для фудтех, медтех, автотех. 

Каждый заказчик хочет знать, на каком стеке будут разрабатывать его продукт. Почему? За этим стоят опасения: будет ли проект поддерживаться в будущем? Получится ли найти на него разработчиков? Вынесет ли большую нагрузку? Получится ли интегрировать его с другими системами? Не произойдет ли так, что технологии уйдут из России, как это было с SAP, Oracle и прочими?

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

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

Инструмент называется Айсберг системного мышления, и сегодня поговорим о нем.

Привет, Хабр! Меня зовут Ахмед, я Deputy CTO в Сравни. 

Сегодня расскажу вам об опыте управления дежурствами в ИТ-команде.

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

Я Саша и я работаю аналитиком домена «Развивающиеся бизнесы» в X5 Tech.
В этой статье на реальном примере я расскажу о проекте, который мы запускали в одном из наших бизнесов – на Фабрике готовой еды (бизнес-единица “X5 Еда”). Запускали, запускали – да не выпустили. Но уроков при этом извлекли массу.

Заказчику задачи в конечном счёте всё равно, какой методологией управления разработкой пользуется команда исполнителей - точная дата получения результата для него важнее.

Чтобы называть эту дату более обоснованно, необходимо понимать, как на самом деле работает команда: сколько поставляет задач, как долго проходит процесс анализа задачи перед взятием в работу, на каких этапах в целом происходит "застревание" задачи.

Под катом - описание метрик и способы их расчёта.