Рубрика «менеджмент проектов» - 6

В конце 2012 года на Хабре промелькнул небольшой опрос «Почему вы не используете облачную инфраструктуру/сервисы в своей компании?» Его результаты весьма показательны для российского рынка SaaS в целом: большинство респондентов считают облачные сервисы либо дорогими, либо небезопасными для хранения коммерческой информации. Тем не менее, количество игроков на рынке облачных сервисов растет и в теперь как сервис предлагаются даже такие «консервативные» и, на первый взгляд, десктопные сервисы, как 1С.

Трудности терминологии

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

  1. неполноценное понимание самой сущности облачных сервисов
  2. многочисленные мифы о стоимости, опасности, нестабильности сервисов.

image
Источник изображения: www.computerra.ru
Читать полностью »

Как мы “адаптировали” agile к условиям удаленного взаимодействия.

Привет, друзья! Данный пост не о преимуществах или недостатках скрама, а о том, как он устроен у нас в распределенной команде.

Кто мы?
Команда разработчиков, находящаяся частично в Самаре, частично в Оренбурге. Заказчик у нас в Москве (неожиданно, правда? :)

Что мы делаем?
Разрабатываем iOS приложение, посвященное тайм-менеджменту по методике Глеба Архангельского. Мы рискнули, несмотря на то, что опыт работы других разработчиков с методикой Тайм Драйв был не особо вдохновляющим. Как вы сможете увидеть в конце статьи, у нас все получилось ;)

Что мы делаем для того, чтобы распределенная команда чувствовала себя единым коллективом и работала эффективно?

1. Ведем бэклог и спринтлоги в удобном Issue tracker’e

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

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

image

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

Посмотрим как они выкрутятся?
Читать полностью »

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

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

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

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

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

Способы оптимизации

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

Что главное?

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

Программы для анализа

Прежде чем заниматься распределением использования времени между проектами надо спуститься в самый низ — понять на что время тратиться на компьютере.
Читать полностью »

Введение

Проработав в IT-сфере порядка 15 лет, я видел несостоятельность многих специалистов, причем, как исполнителей, так и руководителей. Меня всегда поражала апатия и безынициативность людей. Я уверен, что, если человек не в состоянии продуктивно работать как исполнитель, он никогда не сможет эффективно управлять командой. Более того, меня всегда раздражали люди, попавшие на руководящие должности из других, чуждых IT, областей. Таких руководителей технические специалисты обычно не воспринимают всерьез, что и приводит к лицемерию в стиле: руководитель высказал абсолютно бредовую идею, подчиненные сделали вид, что это круто, и пошли кидать лопатами подобный шлак. На выходе от такого менеджмента и, соответственно, такого исполнения задач мы получаем никакой продукт.Прочитав горы литературы, поражаешься, как много было придумано различных теорий и подходов. Консультанты и другие ученые мужи завуалировали и запутали красивыми, но совершенно непонятными, терминами и концепциями простые, по сути своей, вещи. Я считаю, что необходимо откинуть всю эту шелуху и говорить как есть. Смотреть по результатам работы руководителя, а точнее по результатам работы его команды…Читать полностью »

    Я бы хотел обсудить неприятную для многих тему, а именно — ваши иллюзии. Иллюзии и убеждения относительно того комплексного процесса, который называется разработка программного обеспечения. Давайте сразу определимся, что такое иллюзия в данном контексте — это такое убеждение человека, не подкрепленное четкими научными доказательствами.
    Разработка ПО пронизана такими убеждениями на всех уровнях, начиная от выбора языка программирования, переходя на технологию проектирования, и заканчивая технологией управления проектами. Интерпретация результатов результатов успешного проекта, если вы решите проверить какую-то методику на его примере, тоже может ввести вас в заблуждение, если вы не будете настроены максимально скептично. В этом цикле статей я попытаюсь дать вам несколько отправных точек для анализа эффективности той или иной методики разработки. В какой-то мере все, что будет написано далее является просто развернутым описанием основной идеи сайта programming-motherfucker.com.

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

Я в своей жизни неоднократно сталкивался с тем, что многие в ИТ не видят и не понимают разницы между пользователями (users) и клиентами (customers). Думаю, будет полезно прояснить это момент в небольшой статье, хотя для многих тема, которую я попытаюсь раскрыть, будет очевидной. Итак, приступим. Готовы?
Читать полностью »

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

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

Как дизайнеры и разработчики могут играть слаженно (и продолжать бегать с ножницами)
На перевод этой статьи меня побудила статья Кормление и уход за разработчиками (или почему мы такие ворчуны).
Автор той статьи отвечает на топик, приведенный ниже. Для полного видения картины нужно посмотреть на нее с разных сторон. Автор предлагает посмотреть со стороны дизайнера. Кому интересно — под кат.

Как дизайнер, работающий в технически ориентированных компаниях последние десять лет или около того, я трачу много времени на работу с разработчиками. Эти сотрудничества — наиболее конструктивные и плодотворные рабочие отношения, которые у меня были.
Дизайнеры, вы тоже можете создавать эти типы отношений с разработчиками — вы просто должны прорваться через ваши личные предубеждения (как дизайнеров, так и разработчиков), чтобы создать пространство для эффективного партнерства. Если вы успешны, преимущества намного перевешивают любые боли и незначительные изменения необходимые, чтобы этого добиться.
Читать полностью »


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