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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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


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