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

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

Приступим.

Метрики поддержки

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

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

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

Меня зовут Александр, я CEO агентства переводов Kolko Group и студии локализации игр Start Localize. Мы специализируемся на локализации, переводе и работе с контентом, сейчас всё больше фокусируемся на проектах для IT и Gamedev.

Сегодня хотелось бы обсудить со всеми удаленную работу, и как её оптимизировать. Я создавал своё агентство переводов и локализации ещё в далеком 2015 году. Открывая агентство, я ориентировался только на привлечение B2B клиентов, поэтому решил обойтись без офиса и сконцентрироваться только на онлайн-работе. На данный момент в нашей команде порядка 10 человек в штате и 250 на аутсорсе (переводчики, редакторы, верстальщики и копирайтеры), и мы до сих пор продолжаем расти.

Есть, куча вопросов, которые каждый задавал себе в той или иной интерпретации, но не каждый мог на них ответить.
Почему IT — пираты XXI века?

В чём конфликт бизнеса и разработки?

Что общего у керамической чашки и IT‑бизнеса?

Откуда берутся непроницаемые для опыта люди?

Чем схожи кот и плохой инженер?

Рассказал об этом Александр Бындю на встрече комьюнити Skillbox Code Experts. Я облекла наше двухчасовое общение в формат интервью, чтоб поделиться самыми интересными мыслями и тезисами нашей беседы.

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

Как крупным компаниям сохранить высокое качество IT-продуктов, работая с подрядчиками, и сделать внешние команды органичной частью экосистемы? Разберемся на примерах и посмотрим, как решить распространенные проблемы.

Почему крупные компании выбирают аутсорсинг и аутстаффинг?

Для начала давайте разберёмся, почему крупные корпорации все чаще обращаются к подрядчикам. Основные причины лежат на поверхности, но в каждой из них скрыты нюансы.

Годы идут. Джуниорское прошлое уже позади. Ты вроде бы уже тёртый калач, да и деньги платят хорошие. Не 300к в наносекунду, но на пшеничный смузи с вяленой рыбкой хватает. Но что-то не так. Есть стойкое ощущение пустоты впереди. Будто ты никуда не двигаешься. Стрелка компаса хаотично мечется в разные стороны, непонятно, что учить дальше, куда двигаться и "кем ты хочешь стать, когда вырастешь?".

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

USM, НеЖелательные Явления, ненужная документация, допущения и ограничения, тупиковый путь в тимлиды, красные флаги при трудоустройстве и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

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

Пет-проекты (да и просто проекты) айтишников порой выстреливают. Есть много историй, когда кто-то что-то сделал один на коленке или в гараже с друзьями, и это потом стало приносить пользу людям и признание автору. Например, мы знаем, что проект карманного мультитула для пентеста Flipper Zero родился из идеи Павла Жовнера. Он пилил его с друзьями, и проект неплохо выстрелил. Но у Павла, как говорится, с самого начала был какой-то план, и он его придерживался :) А некоторым стартапам порой может не хватать знаний: идея есть, а что с ней делать — не очень понятно. Или уже даже есть MVP, но как привлечь инвестиции и пройти все преграды, мало кто знает.

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

Привет, на связи Технократия, и сегодня Head of Web компании Айзат Фархутдинов расскажет о том, как мы решали проблему актуализации статусов проектов: от заполнения табличек в Google Sheets до разработки полноценного сервиса, в котором есть функция суммаризации статусов.

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

Да, промышленное оборудование - безусловно критически важное оборудование инфраструктуры предприятия и от надежности такого оборудования во многом зависит доход компании.

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

Возьмем например банк. Инженерные системы и системы противопожарной безопасности банка – это «сердце», жизненно важный элемент объекта. Кассовая техника – это «стержень» кассового узла, центра пересчета. Исправное и безотказное состояние элементов инженерных систем обеспечивает удобство, уют и комфорт сотрудникам и клиентам банка, а кассовой техники – непрерывность процесса пересчета и, как следствие, напрямую влияет на прибыль.

Наша команда Банка ВТБ давно занимается этими вопросами и мы хотим рассказать об одной такой истории автоматизации процессов ТОиР в банковской сфере.

В 2020 году Банк ВТБ, как и положено крупным компаниям, обновлял программное обеспечение и переходил на обновленную версию SAP S4. Управление эксплуатации Административного департамента банка, проанализировав текущие процессы ТОиР, вынесла предложение включить в новую сборку программы SAP дополнительный модуль PM (ТОРО). Руководство компании поддержало идею цифровизации технического обслуживания и ремонта. Так началась история автоматизации ТОиР в Банке ВТБ.

Для кого может быть полезна эта статья:

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

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

По мотивам откровения пьяного старшего инженера.

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

Добрый день, читатели!

С чего обычно начинаются веселые проекты? Хочу поделиться одной историей длиной в 3 года.

Треть компаний следят за своими сотрудниками во время работы (hh.ru). Четверть — следит за их соцсетями (UTEAM).

Процессы в командах — больная тема. Где-то в команде, состоящей из сеньоров, лидов, star-level-devs и одного РП, изменение процесса приводит к проседанию разработки в полтора раза. А на каком-нибудь стартапе джуны при командной оценке страдают от однообразия и ожидания своей очереди.

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

Сфера проектирования вышла на новый уровень с появлением BIM-технологий. Помимо стандартных «коробочных»‎ решений, во многих САПР реализована возможность использования API для расширения базового функционала инструментов.

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

Основные цели автоматизации проектирования — это сокращение трудозатрат проектировщиков и улучшение качества финального продукта.

Внедрение автоматизации стало доступным, но как ее внедрять, чтобы она была поддерживаемой и расширяемой? Что делать, когда плагинов становится слишком много? А если проблемы качества кода и его структуры становятся актуальными? Если над разработкой таких плагинов теперь работает не один человек, а целая команда? И кто такой Октавиан?

Одна из причин этих сложностей ясна: при внедрении BIM нет общего видения, как должна выглядеть система целиком. Многие разработчики плагинов не обладают опытом разработки до того, как начинают их писать. Часто отсутствуют технически подкованные коллеги, которые смогут научить и спроектировать структуру «на берегу»‎. 

С такими проблемами мы и столкнулись в нашей команде проектной автоматизации ПИК — и пришли к созданию своего фреймворка ReactiveBIM, который уже несколько лет показывает себя с хорошей стороны. 

Чтобы не вводить в заблуждение: слово «Reactive»‎ не имеет отношения к реактивному программированию, а подчеркивает ускоренное погружение новых специалистов в разработку плагинов для автоматизации BIM-моделирования.

ReactiveBIM — это платформа с открытым кодом для разработки плагинов для CAD/BIM программного обеспечения. Эта платформа предлагает разработчикам надежную структуру проекта, внедрение зависимостей, легкую настройку, удобное ведение журналов, автоматизацию сборки пакетов и многое другое.

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

В статье будет рассматриваться только часть фреймворка для Revit, но функционал включает в себя также поддержку Autocad.

Приятного чтения!

Эффективное управление проектами требует гибкости и прозрачности — особенно когда речь идет о крупном бизнесе, работающем с чувствительной информацией. Для этих целей был создан Атом.Проект, который мы теперь используем и внутри компании. Меня зовут Александр Кобозев, я директор практики в блоке BI и практике BigData Лиги Цифровой Экономики. В этом материале расскажу, как функционирует разработанная платформа для управления проектами и как именно она способна улучшить рабочие процессы.

Думаю, все любят разрабатывать новый функционал приложений, сервисов, микросервисов и пр. И наверное, мало кто любит заниматься инфраструктурными работами. Например, портировать код на другую операционную систему или портировать код на другую микропроцессорную архитектуру, или же «отвязывать» вычислительную логику от графических интерфейсов (если вдруг приложение долгое время развивалось так, что отделение вычислений от графики никого не заботило)…

Тем не менее, инфраструктурные проекты тоже важны, и время от времени их приходится делать.

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

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

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

Для начала представлюсь — я разработчик с более чем 15-летним стажем. За это время я работал в самых разных компаниях — от маленьких стартапов до крупных корпораций, в одиночку и в больших командах. Хочу рассказать о несправедливости в IT, с которой мне пришлось столкнуться.