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

в 10:15, , рубрики: svn для дизайнера, веб-дизайн, менеджмент проектов, планирование, работа в команде, управление проектами, метки: , , , ,

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

image

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

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

в 11:41, , рубрики: Веб-разработка, веб-студия, дизайн студия, менеджер задач, менеджмент интернет-проектов, менеджмент проектов, разработка, разработка по, разработка сайтов, управление проектами, управление проектами и командой, Управление проектом, метки: , , , , , , , , , ,

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

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

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

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

в 12:10, , рубрики: менеджмент персонала, менеджмент проектов, оптимизация рабочего времени, поисковая оптимизация, работай над собой, фриланс, Читальный зал, метки: , , ,

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

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

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

Что главное?

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

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

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

в 8:40, , рубрики: ит, менеджмент, менеджмент проектов, управление проектами, метки: , ,

Введение

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

в 18:41, , рубрики: agile, менеджмент персонала, менеджмент проектов, Оценка и экспертиза IT-проектов, проектирование, разработка, управление проектами, метки: , , ,

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

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

в 17:53, , рубрики: SaaS / S+S, Блог компании «Knoema», клиенты, ликбез, менеджмент проектов, пользователи, продукты, сервисы, управление проектами, метки: , , , , ,

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

в 12:48, , рубрики: agile, менеджмент проектов, управление людьми, управление проектами, метки: , ,

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

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

в 11:12, , рубрики: Дизайн в IT, менеджмент персонала, менеджмент проектов, разработка, управление проектами

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

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

в 10:32, , рубрики: менеджмент персонала, менеджмент проектов, разработка, управление проектами

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как в русском языке полноценного эквивалента нет, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

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

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.
Читать полностью »

в 9:19, , рубрики: интеграция, менеджмент проектов, риски, метки: , ,

Управление проектами / Интеграция сайта с 1С — риски и немного реальности
Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…
… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.
Рассмотрим процесс интеграции с точки зрения клиент-исполнитель. Сценарий продажиЧитать полностью »

1...456
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js