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

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

Но предел моих мечтаний, конечно – менеджер, который Всё Унифицировал. Тот, у которого Единый Процесс. Самый Лучший, разумеется. Или даже Единственно Верный.

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

Не прав именно я, не дорос ещё. Рано мне уверенно утверждать, что правильно, а что нет. Я должен пройти Путь, который, наверняка, прошли программисты, тимлиды, проджекты и менеджеры моей мечты.

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

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

Думал-думал я, и придумал. Не надо притягивать за уши контекст. Надо устроить конкуренцию внутри одного контекста. Внутри одной компании. Даже – внутри одного отдела. Благо, у меня есть отдел.

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

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

Поэтому я стал эволюцию подпинывать. Как? Ну, как учёные в лабораториях с крысами. Проактивно, по собственному желанию.

У меня есть знакомый в возрасте, который «хомячит» гаджеты: единовременно у него есть кнопочный телефон, смартфон Android, ещё один Android побольше, планшет, iPhone. Всё работает, всё оплачивается, где нужен интернет — есть безлимит, а сверх всего этого фигачит портативный роутер Yota. На одном гаджете — видеозвонки и фильмы, на другом — новости в ста закладках, на третьем — Angry Birds и музыка, кнопочный — для звонков и улицы. На любые аргументы, что всё это есть в одном гаджете (ну ладно, пусть ещё планшет будет), ответ один: так задумано. Что в итоге? Переплата за связь и интернет около 1000 в месяц, лёгкая нервозность от количества переключений между экранами, необходимость всю эту гвардию чистить, заряжать, обновлять, докупать шнуры и т.д. — проблемы усложнённой персональной инфраструктуры.

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

В ноябре мы провели двухдневный хакатон T1 Digital Challenge. 18 команд боролись за призовой фонд в 500 тысяч рублей и решали две задачи: создание корпоративных решений с помощью No-Code и Low-Code платформ, и улучшение пользовательского опыта (CX, Customer Experience). К слову, это уже второй наш хакатон — в августе на CRM Hack участники создавали «киллер-фичи» для нашей CRM-системы. 

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

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

Понятие «бирюзовые организации» (они же «живые организации) было впервые описано в 2014 г. Фредериком Лалу в книге «Открывая организации будущего». Согласно его градации, бирюзовые организации стоят на вершине эволюционной цепи и наилучшим образом соответствуют сегодняшней действительности.

Бирюзовые организации стоят на трех китах...

Мир ИТ-услуг весьма странен.

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

С другой стороны, продолжают покупать. Это понятно – выбора-то особо нет. Будь на рынке реально крутые, качественно лучшие игроки – законы конкуренции доделали бы остальное.

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

Итог всегда один, просто достигается за разное время, кому как повезёт. Кому-то выпадет счастливый билет, и попадётся действительно классный программист или целая команда. Но это лишь продлит агонию – никакой программист, и никакая команда не будет с заказчиком всегда. Штурмовые бригады идут дальше, а на замену приходят охранные войска – ополченцы, грубо говоря. И разочарование заказчика ИТ-миром в целом произойдёт обязательно.

А бывает ли по-другому? Речь не про сказку об очередном мифическом деревенском программисте, который с пинка открыл дверь собственника и всё ему объяснил, нет. Бывает ли так, что не обманываются ожидания?

Конечно. Чтобы не обманывались ожидания, рычага есть два. Первый – соответствовать ожиданиям. Второй – корректировать ожидания. Я сегодня про второй.

Есть у нас команда, которая…. Как бы это выразиться. Странная короче. Они говорят заказчику всё, как есть. И предлагают выбор.

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

Прекрасный мир, почти нирвана... если бы не вот это ЕСЛИ, которое является дверью в совсем другое измерение.

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

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

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

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

Когда всё падает — это нормально. Особенно в IT. Даже Марку Цукербергу периодически приходится извиняться, когда сбой в работе соцсетей приводит к миллиардным потерям. Надеемся, что у вас таких потерь не будет, поэтому поговорили с разработчиками, тимлидами и менеджерами. Спросили, что и как нужно делать, когда всё плохо, чтобы не навредить карьере. 

Всем привет. Меня зовут Алексей Демешко, я основатель и руководитель Alente — крупнейшего digital-агентства в Красноярском крае. На момент написания статьи компании 12 лет, в штате порядка 50 человек. 

Обычно digital-проекты открывают люди, раньше работавшие дизайнерами или технарями. Моё образование разрывает шаблоны и заодно является причиной, почему набил так много шишек: я лингвист-переводчик. 

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

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

Меня зовут Александр Глухов, я в финтехе с 2013 года. Сейчас работаю в Ак Барс Банке и оптимизирую процессы в мидл-офисе и бэк-офисе. Мы делаем разные продукты для банка, один из них — универсальное рабочее место сотрудника. Это внутренний сервис для сотрудников банка, которые рассматривают кредитные заявки и после всех проверок решают, давать кредит или нет.

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

Эта статья — расшифровка доклада с митапа Three Amigos Talk.

В вашем списке дел на день и так 10 пунктов, но клиенты и коллеги накидывают еще в виде срочных вопросов или асапных задач? Есть ощущение, что вы весь день решали проблемы и с кем-то общались, но ваш to-do list не уменьшился? К сожалению, так работают многие. Мультизадачность все еще норма, несмотря на то что она не только не способствует повышению продуктивности, а, напротив, снижает ее. А еще вызывает стресс, ухудшает память и ускоряет наступление усталости. Об этом говорят многочисленные исследования, о которых мы расскажем ниже.

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

В январе 2021 года я закончил работу с Хабром по формированию их новой стратегии. Мы описали стратегию в формате Х-матрицы, дальше ребята сказали, что сами декомпозируют X-матрицы на департаменты, и спросили, с помощью какой системы лучше реализовывать стратегию. Я ответил, что на сегодняшний день не знаю ничего лучше OKR (Objectives and Key Results): она гибкая, не требует особых знаний и понятна всем, кто так или иначе сталкивался с Agile. Мы ударили по рукам и разошлись.

Однако уже в мае ко мне постучались Денискин и Баксли с просьбой посмотреть, что не так. Ребята попытались сами внедрить ОКR, но что-то пошло не так, и система не приживалась. После небольшого анализа был выявлен ряд ошибок, основной из которых у Хабра, на мой взгляд, стала попытка внедрения сразу во всей компании.

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

Овертаймы - это, наверное, одна из самых интересных и резонансных тем в работе разработчиков. Возможно ли их избежать в работе над такой ААА-игрой, как Ori WotW? Немного забежим вперед и скажем, что если бы это было так, то мы бы наверняка не писали бы эту статью, но об этом дальше :)

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