Управление проектами

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

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи «Управление разработкой в «горизонтальных» компаниях», где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан. 

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

В основе многих наших действий или бездействий лежат неразрешенные конфликты.

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

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

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

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

Многие практики Теории Ограничений утверждают, что «Грозовая туча» работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

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

Таск-треккер как исправный источник данных для стратегического управления. Звучит красиво. А в нашей компании это даже работает и приносит пользу.

Данная статья является углублением к предыдущей: Автоматизация аналитики Jira средствами Apache NiFi. Теперь хочу подробнее раскрыть наш взгляд на отчетность по Jira Software и опыт ее реализации при помощи R. Язык тут, конечно же, не догма. Сегодня наше все — это концепция.



Картинка позаимствована тут.

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

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

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

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



А теперь поговорим обо всем этом подробнее.

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

фото с сайта pilot.com

В 2012 году Джессика МакКеллар с командой друзей из MIT (Массачусетский Технологический Институт) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.

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

Многие компании также пытаются стимулировать такую активность работников – в Google было правило 20%, которое привело к рождению Gmail, AdSense и Google News, а в Twitter инженеры получали неделю свободную от обычных обязанностей для экспериментов – найти вакансии от столь же продвинутых компаний можно через бота @g_jobbot.

Да что далеко ходить – недавно мы делали вебинар с Android-разработчиком Дмитрием Рязанцевым (вот его статья про работу на Toptal) – запущенную им игру Draw and Ride скачали 250,000 раз, а начиналась она именно как pet-проект. Звучит вдохновляюще, но насколько подход pet-проектов актуален в конце 2020 года? Считают ли до сих пор инженеры наличие таких проектов важным для себя и профессионального развития? С какими проблемами сталкиваются те, кто ими занимается? В новой статьей мы решили найти ответы на эти вопросы.

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

Такая история произошла с моим знакомым, который имел вполне успешный бизнес в офлайне. Наблюдая за успехами таких сервисов, как avito и carprice, он решил запустить аналогичный онлайн-сервис по продаже недвижимости, в которой у него был 10-летний опыт.

Идея монетизации — оплата за размещенное объявление об объекте и помесячная подписка на расширенные инструменты для продажи недвижимости.

Для этого заказал разработку функционального онлайн-сервиса с внутренней CRM-системой, мессенджерами и сложной системой аналитики за 1.5 млн. рублей и 5 месяцев работы, снял офис, нанял менеджеров и запустил рекламу.

Примерно за полгода затраты превысили 2,5 млн. рублей и, судя по динамике, это было только начало.

30  октября мы провели встречу с СТО и техническими руководителями Райффайзенбанка, Mindbox и ЦИАН, где за два часа постарались максимально охватить непривычную для российского рынка IT-компаний тему управления разработкой без менеджеров. В ходе разговора выяснилось, что «плоскость» («горизонтальность») у каждой из приглашенных компаний — своя. Под катом — видео со встречи и расшифровка первой ее части.

Митап был длинный и насыщенный, поэтому мы разделили его на два поста: первый, вы читаете его сейчас, — это ответы гостей на вопросы, которые выбрали в нашем сообществе в Фейсбуке; вторая — ответы на вопросы «из зала» от слушателей — выйдет на следующей неделе.

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

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

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

Почему именно бомбоубежище? Ответ прост: это было идеальное место с доступом к электрическим мощностям завода, близко к оптоволоконным магистралям на MSK-IX и MSK-X. А ещё не было конкуренции за место, потому что вряд ли кто-то захотел бы для себя такой офис или склад. Ну и три контура охраны, поскольку завод всё ещё непростой, что в перспективе позволяло очень легко хранить персональные данные.

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

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

• Мария Чебакова, руководитель группы оптимизации процессов. Отвечает за формирование и настройку бизнес- и операционных процессов.
• Антон Сокольников, руководитель проектов в направлении логистики. Отвечает за развитие логистических продуктов.
• Станислав Ураков, руководитель разработки в направлении логистики. Отвечает за систему, архитектуру и архитектурные решения, а также команды разработки.

Давным-давно в далекой-далекой галактике появился проект The Bell, построенный на WordPress. Постепенно проект рос и развивался, добавлялись всевозможные галочки и тоглеры, накручивались фичи. Технический долг копился и тащил The Bell на тёмную сторону, а новые хотелки уже выходили за рамки возможностей CMS и превращали проект в колесо с костыликами вместо спиц. И тут редакция задумала обновить сайт и сделать редизайн новостной ленты.

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

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

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

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

Всем привет!

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

Источник

В автоматизации бизнеса часто встречаются т.н. «проекты-проститутки» (термин не я придумал). Это клиенты, над решением задач которых поработали толпы разных людей, без единого центра принятия решений, какого-либо анализа, продуманной архитектуры и здравого смысла. Клиент просто придумывает хотелку, программисты просто реализуют.

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

Клиента, понятно, такой подход раздражает. Только привыкли к одному спецу, или хотя бы запомнили его имя и телефон, как получают другого. Нужно заново всё объяснять, показывать, а то и платить за «проанализировать, как у вас всё устроено» — документации, естественно, никогда нет. Большинство клиентов уже смирились, потому что поняли – так везде, в любой конторе по автоматизации, даже у фрилансеров.

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

Сколько сказок об управлении проектами вы слышали? Лично я — множество. Прошерстив известный мне список, выделила 5 призовых мест — самых популярных мифов, которые я слышала о проджект менеджменте.

Откуда берутся мифы?

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

Быстрое питание, быстрые встречи, быстрые результаты, быстрый интернет… В 21 веке мы хотим, чтобы все было быстро и просто. И еще одно: нам нужна быстрая коммуникация. Лучшее решение это текстовые сообщения. Пользователи iOS используют iMessages, но как насчет пользователей Android? Ответ прост. RCS сообщения!