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

Прошло уже больше года с тех пор, как вся IT-индустрия форсированно уехала “по домам”. Но о том, как эта смена режима повлияла на нашу работу сказано не так уж и много. Изредка попадаются заметки в узкоспециализированных изданиях или не самых  профильных. И не ясно: то ли все стараются избежать репутационного ущерба, ведь “удаленка у нас не летит” — это уже своеобразный “ярлык отсталости”, то ли плюсы так сильно перевешивают минусы, то ли даже спустя год все еще “не до того”. Однако влияние удаленки весьма велико. И несмотря на то, что топик ни разу не технический, предлагаю его обсудить.

Все, так или иначе, используют Open Source. Но что делать, если нам нужна новая фича или мы нашли критический баг? Можно, конечно, форкнуть репозиторий и быстро что-то поправить. Но форк нужно поддерживать, а новая версия может оказаться несовместимой с вашей. Например, GitHub потратил полтора года, чтобы обновить фреймворк Ruby on Rails с версии 3.2 до версии 5.2.

Можно отправить pull request. Так вы решите не только свою проблему, но и поможете сообществу. Но у мейнтейнера есть свой Open Source проект и контрибьюторы ему обычно только мешают. Поэтому ваш pull request могут не принять. И первый, и второй, и  десятый.

Как же тогда работать с Open Source? Михаил Грачёв, тимлид из Evrone, расскажет,  как в компании выстроили работу с Open Source и превратили это в культуру. Для тех, кто предпочитает смотреть видео — запись его выступления на TeamLead Conf 2021.

Если вы пересекаетесь с вашим линейным менеджером только тогда, когда нужно подписать отпуск или приходите к нему с оффером от другой компании, то что-то идёт не так. Чтобы получать качественный фидбек и расти в желаемую сторону нужно понять, что проведение 1:1 это не обязанность вашего менеджера, а ваша общая. Стоит помнить, что с менеджерами работает такое же правило, как и с разработчиками: хороших меньшинство. Так что если вы оставите проведение 1:1 полностью на них, то рано или поздно вы разочаруетесь. Тут я собрал основные советы о том, как подходить к 1:1 разработчику (на самом деле эти же правила применимы и для любой другой специальности).

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

В сфере управления проектами в компании Orion Innovation я применял разные практики и сформулировал несколько выводов, которыми хотел бы поделиться.

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

В российских компаниях классический путь программиста заканчивается на должности тимлида или tech lead. Дальше — всё больше менеджера, всё меньше инженера. Хочешь расти в компании — берись за управление людьми, нравится тебе это или нет.

Но что, если есть другой путь? Опыт западных компаний показывает, что можно дать программисту остаться в разработке, а в менеджеры брать тех, у кого есть желание. И это не пойдёт компании в убыток. Наоборот — разработчик сможет вносить больший вклад в работу компании и наработать уникальную экспертизу. А ещё не выгорит от бесконечных code review. В этой статье Иван Круглов расскажет, как разработчику расти, минуя менеджмент.

Введение

Вторая статья цикла, посвященного ОУД, рассказывает о проблеме с позиции разработчика прикладного ПО (или заказчика, который должен получить гарантии безопасности конечного продукта).

Давайте ненадолго абстрагируемся от ОУД. Представьте, что вы разработчик и создаете приложение для финансовых или кредитных организаций, подшефных Банку России. Или вы работаете в одной из таких организаций - банке, страховой, брокере, и являйтесь заказчиком продукта. Вы очень хотите гарантировать определенный уровень качества, и даже если не хотите - существующие SLA, нормативы регуляторов и требования контрактов заставляют прорабатывать не только функциональные требования, но и вопросы информационной безопасности. С чего же следует начать?

Среди типов систем планирования все большую популярность приобретают системы класса APS — Advanced Planning and Scheduling («система продвинутого планирования»).

Наша компания CS Group является официальным партнером французской компании Dassault Systèmes и работает с одним из ее лучших программных решений класса APS-систем — DELMIA Ortems. Оно обеспечивает оптимизацию за счет планирования и составления графиков связанных производственных процессов. Говоря проще, мы загружаем в систему некоторые входные данные, а на выходе получаем оптимальный производственный план.

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

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

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

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

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

Начиная с этой версии мы окончательно прекращаем поддержку устаревшего REST API.

Далее расскажу обо всем подробнее.

При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19. 

Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее. 

Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов. 

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

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

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

На что мой руководитель резонно мне ответил:

— ${zloy_stas}, таких, как этот Г., в твоей работе будет много; если ты будешь увольнять каждого, кто тебе не понравился лично, ты быстро перестанешь быть руководителем. Твоя задача — не детей с ними крестить, а извлекать из них пользу и уметь с ними работать. Пусть этот Г. будет для тебя таким менеджерским челленджем.

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

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

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

Меня зовут Татьяна, я Team Coach R&D компании Plesk, и большую часть конфликтных ситуаций в командах мы проживаем и решаем с тимлидами вместе. 

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

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

На TeamLead Conf 2021 я поделилась преградами, которые мы преодолели, сделанными ошибками, выработанным подходом и рецептами, которые сработали. Неожиданно доклад попал в ТОП-3. Можно совместить чтение и прослушивание видео с выступления.

Контента оказалось много, поэтому коллеги из Онтико предложили разбить его на части и написать по мотивам доклада две статьи. Поэтому рада поделиться сегодня первой историей о нашем подходе к решению конфликтов (больше теория), а статья с конкретными кейсами (практика) выйдет через неделю.