Рубрика «управление проектами» - 109

Управляем большим длинным проектом: почему важно разговаривать словами - 1

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

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

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

Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

Задержки продолжили копиться.
Читать полностью »

Больше, чем государство: Британская Ост-индская торговая компания - 1

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

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

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

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

Оставалось думать. Это было непривычно, поэтому результат тоже получился неожиданный.
Читать полностью »

Отлично, мы собрались DevOps-нуться. Получается, 15 лет процессов планирования — коту под хвост? - 1

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

DevOps существует почти 10 лет, и в последние два-три года большие нормальные организации уже освоились с премудростями DevOps. («Но что такое этот ваш DevOps?!» — вероятно, подумали вы. Договоримся, что это «улучшение качества вашего ПО за счёт ускорения цикла релизов с помощью облачных методик и автоматизации, а также с помощью дополнительных преимуществ ПО, которое остаётся в production».)

Когда Мэтта Карри, менеджера по Agile-трансформации в компании Allstate, спросили о применении DevOps, он ответил: «Думаю, когда айтишники его опробуют, то уже никогда не будут работать по-другому». Вероятно, вы слышите подобное вновь и вновь, когда речь заходит про внедрение DevOps.

Хотя внесение улучшений и изменений часто кажется чем-то, что не может произойти в вашей организации, результаты слишком заманчивы, чтобы их игнорировать, да и бизнес ожидает от ИТ последовательного наращивания возможностей и эффективности. Как сказал Джон Митчелл, директор по цифровой стратегии и поставке компании Duke Energy: «Согласно нашим бизнес-результатам, стало в 10 раз лучше».
Читать полностью »

Привет, меня зовут Билл «LtRandolph» Кларк. Я работаю техническим руководителем команды создания чемпионов LoL. За последние несколько лет я успел поработать в разных отделах разработки League, но единственное, чем я был постоянно одержим — это технический долг. Мне нужно найти его, понять его и, при возможности, устранить его.

Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».

Riot Games: анатомия технического долга - 1

Метрики

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

И снова всем привет. Цикл «SOC for …» продолжает свое движение и развитие. Первый слой внутренней кухни центров мониторинга и реагирования на инциденты мы уже успели осветить в предыдущих статьях, поэтому попробуем понемногу пойти вглубь, к техническим подробностям и более тонким проблемам.

Мы уже несколько раз косвенно касались темы управления активами: и в статье про контроль защищенности, и в вопросах автоматизации и искусственного интеллекта в SOC. Очевидно, что без инвентаризации инфраструктуры заказчика центр мониторинга не сможет его защищать. При этом составить ее детальное описание отнюдь не тривиальная задача. И главное — через пару месяцев оно снова не актуально: одни хосты исчезли, другие появились, возникли новые сервисы или системы. Но защита инфраструктуры — процесс непрерывный, и SOC не может притормозить свою деятельность до получения актуальной информации об активах заказчика. Напомню, качество работы Solar JSOC регулируется не абстрактными обещаниями, а вполне конкретным SLA, за нарушением которого следуют различные небесные кары. Как выкрутиться в такой ситуации и не потерять в качестве оказываемого сервиса?

SOC for intermediate. Разбираемся в том, что защищаем, или как провести инвентаризацию инфраструктуры - 1
Читать полностью »

Как создать стартап-империю, не продав при этом своей свободы - 1

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

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

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

Мы встретились, чтобы обсудить плохие новости.

Его только что выгнали из стартапа, который он сам же и основал два года назад.

Он и не подозревал, что у него за спиной инвесторы и сооснователи вынашивают чудовищный план.

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

Ему пришлось не только сложить с себя полномочия CEO: его также вынудили расстаться с теми немногими акциями, которые он себе оставил в собственноручно созданном стартапе.

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

И эти же инвесторы захотели его выгнать.

Переведено в AlconostЧитать полностью »

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

Читать полностью »

image

Создавать игры сложно

И самая сложная часть создания игр — это препродакшен. Это заявление может показаться обескураживающим. Все мы слышали о очень тяжёлых периодах продакшена игр и часто видели лёгкие, простые и интересные периоды препродакшена. Почему же я утверждаю, что препродакшен сложнее? Потому что один из аспектов, способных отравить продакшен — это выполняемый во время него препродакшен. Как бы ни был сложен препродакшен, гораздо сложнее (и намного дороже) выполнять его на этапе продакшена. Позвольте объяснить: в идеальном мире никто не брался бы за производство коммерческой игры, которую ждёт провал. Если вы намереваетесь создать игру с целью извлечения прибыли, и вы знаете, что игра прибыль не принесёт, то к продакшену вы не перейдёте.

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

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

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

MBO, OKR, PPR: смешивать, но не взбалтывать - 1

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

Привет. Меня зовут Максим Винников, я Vice President of Product Management в компании Aurea Software. В той же самой компании, на которую работает Слава Кулаков, знакомый многим по истории, как он стал фрилансером, получающим $200 000 в год. Вопросы и комментарии к тому посту продолжают идти до сих пор, поэтому сегодня, уже на своём примере, я расскажу, что из себя в повседневном режиме представляет уже непосредственно работа, за которую платят такие гонорары — и постараюсь ответить на вопросы по теме живьём.

Отвечаю на ваши вопросы в прямом эфире:

Согласно стандартам Aurea и ESW Capital каждый сотрудник должен отработать 40 часов в календарную неделю. Я, исходя из своей позиции и физических возможностей, придерживаюсь графика 5/2. Моё основное рабочее окно расположилось в промежутке с 14:00 до 19:00, это суммарно 5 часов в день. Ещё 3 часа в день дорабатываются тогда, когда мне удобнее: в один день я могу поработать поздним вечером, в другой — приступаю с самого утра, чтобы освободиться пораньше.

Так как команда на 100% децентрализована и у нас нет офисов, то всё взаимодействие между сотрудниками переходит в онлайн. Я, как VP (а это менеджерская позиция), вовлечён в различные рабочие процессы множества людей сильнее, чем среднестатистический разработчик. Это тоже стоит учитывать.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js