СТАТЬИ АРБИР
 

  2016

  Декабрь   
  Пн Вт Ср Чт Пт Сб Вс
28 29 30 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31 1
   

  
Логин:
Пароль:
Регистрация
Забыли свой пароль?


Основные проблемы в управлении it-проектами

Мы работаем в «век кибернетики и атомной энергии», все в мире непрерывно и стремительно изменяется, инновации - неотъемлемый атрибут нашего времени. Изобилие стало причиной острейшей конкуренции. Практика должна постоянно перестраиваться применительно к новым условиям (например, Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали) [1].

Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора. Работники интеллектуального труда начинают самостоятельно определять себе цену. Интеллектуальное творчество очень сложно нормировать и контролировать, в том числе и программирование, как один из видов творческой деятельности. У разработки программного обеспечения есть свои законы и специфические особенности, которые, в силу молодости отрасли программной индустрии, мало изучены. Профессиональное творчество программиста принципиально отличается от творчества в науке и искусстве. Программистские задачи с каждым годом становятся все сложнее и объемнее, а сроки, за которые требуется решить эти задачи, наоборот, с каждым годом сокращаются. Поэтому современные программные системы создаются коллективами от нескольких до тысяч программистов. При этом в программировании мало повторяющихся задач, нет места для репродуктивной деятельности. После третьего повторения однотипного действия программист пишет утилиту, которая это действие автоматизирует раз и навсегда. Однако оказалось, что использование лучших языков и технологий программирования, самых совершенных инструментов разработки и систем качества не гарантирует успешность программного проекта. «Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте» [2]. Творческими командами разработчиков ПО практически невозможно управлять, их можно только направлять и вести. А для этого недостаточно быть эффективным управленцем, необходимо еще получить признание от команды в качестве лидера.

Все проекты в сфере информационных технологий движутся за счет бизнес-требований. Для руководителя проекта сложность представляет перевод данных бизнес-требований в конечный продукт, который будет удовлетворять всем нуждам бизнеса. Программисты используют весьма развитый и специфический технический язык, в том числе и в отчетах. Управление проектом означает управление людьми, а если вы говорите на двух разных языках, то это весьма проблематично. В том и заключается фокус - вы должны уметь общаться с людьми, которыми управляете. И хотя технический язык в большинстве случаев не нужен, так как все, что нужно знать о проекте, может быть выражено обычным деловым языком, руководителям IT-проектов все же стоит уделить свое время на понимание проекта, которым они управляют, именно с технической стороны. Это следует сделать как минимум ради того, чтобы предоставить проект должным образом, также чтобы перевести проект на язык бизнес-плана, функционального описания, сетевого графика, рекламного проспекта. Самым важным в работе руководителя проекта является то, что он выступает посредником между программистами и «остальным миром». Он может выносить на обсуждение необходимость изменения процессов, представлять результаты труда программистов и защищать те их интересы, которые положительно повлияют на работу компании.

Если говорить о техническом понимании проекта, то начать стоит с понимания ошибок, чтобы знать, когда стоит позволить технической команде решать проблемы, а когда лучше приводить их к решению. «В какой-то момент придется действовать решительно, потому что вы несете ответственность в качестве руководителя проекта, а средний программист, хотя и выглядит, как взрослый, умный и ответственный человек, который умеет поставить задачу и обосновать запрос на выделение ресурсов, при этом на деле он постоянно ведет себя как школьник: не говорит всей правды, ошибается со сроками, срывает проекты» [3]. Вы - руководитель проекта, и потому темп разработки, при котором можно достичь приемлемого качества, целиком в вашей власти.

Нужно помнить, что в бизнесе выигрывают менеджеры и бизнесмены, и как бы гениален не был разработчик ПО - он, чаще всего, не является ни тем, ни другим. Источники успеха проекта всегда лежат вне сферы технологий - в сфере бизнеса, а разработчик в среднем не стремится помочь организовать и развить бизнес. Истинные мотивы большинства разработчиков - авторские, т. е. речь идет только об интересной работе. Успех продукта или компании в смысле роста прибыли интересует разработчика только опосредованно. Если дать программисту волю, то он использует только на разработку общей платформы 100% времени и денег, а продукт никогда не выйдет на рынок. Однако авторские мотивы очень сильны и их можно эффективно использовать для работы компании.

Разработчики, как правило, называют неверные сроки, они просто заблуждаются на счет трудоемкости работ, причем это происходит постоянно, поэтому нельзя рассчитывать, что программист, уже однажды совершивший эту ошибку, сейчас называет реальные сроки. Одним из парадоксальных условий для работы с программистами является отсутствие жестких сроков на выполнение задачи как условие свободы. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов эффективной работы. «Бессмысленно заставлять программистов работать больше, чем они могут. Работать больше, это совсем не значит - работать продуктивнее. Наоборот. Задача не будет решена за любое отведенное на нее время, если у программиста нет желания это сделать. Или сумейте мотивировать программиста на выполнение задания, или передайте его задачу другому участнику проекта. Иного пути нет» [4]. Часто бывает ситуация, что программист не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу. Это и есть авторский мотив в работе программиста.

Все мы прекрасно знаем, что работникам умственного труда лучше всего работается, когда они погружаются «в зону концентрации», или, так сказать, в «трудовой поток», полностью концентрируются на задаче и отключаются от внешних воздействий. Они забывают о времени и в состоянии чрезвычайной сосредоточенности выдают превосходные результаты. Однако же, войти в «зону» нелегко, а выйти очень легко. Программистам особенно тяжело. «Их труд основан на одновременном жонглировании в кратковременной памяти огромным количеством мелких деталей. Всякое прерывание сбивает жонглера, и шары с грохотом летят вниз. А потом деталей этих никак не вспомнить (как называется эта переменная? в каком месте вылетает цикл?) и приходится шарить по полу в поисках нужного шара, и работа застопорится, пока вы не соберете все»[5]. В этом и есть особенность - у программистов переключение между задачами происходит очень долго. Это такое занятие, при котором приходится держать в голове много деталей одновременно. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются. Отсюда вывод, даешь человеку задание, он его отлично выполняет, но даешь два задания одновременно, а результат гораздо хуже. Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что «улитки обгоняют» [5]. Это потому, что переключение между программистскими задачами происходит медленно. Мораль всего этого в том, что не следует давать людям работать более чем над одной задачей одновременно.

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

Библиографический список

Кови С. Р. 7 навыков высокоэффективных людей. Мощные инструменты развития личности. 2-е изд. М.: Альпина Бизнес Букс, 2007.

Коуберн А. Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения // Humans and Technology. 1999. Октябрь. maxkir_com/sd/people_as_nonlinearRUS.htm.

Ашманов И. Правила Ашманова. ashmanov_com/ pap/ashrul2.

Архипенков С. Руководство командой разработчиков ПО. Прикладные мысли. happy-pm_com/sw_team_management.pdf.

Спольски Дж. Human Task Switches Considered Harmful. local.joelonsoftware_com/




Д. Г. Прокопьев, Д. А. Татарников, Н. Ю. Шрайбер Национальный исследовательский Томский политехнический университет (Томск, Россия)


Управление интеллектуальным капиталом. Материалы Международной научно-практической конференции (Екатеринбург, 27 апреля 2012 г.) Екатеринбург: Издательство Уральского государственного экономического университета, 2012.



МОЙ АРБИТР. ПОДАЧА ДОКУМЕНТОВ В АРБИТРАЖНЫЕ СУДЫ
КАРТОТЕКА АРБИТРАЖНЫХ ДЕЛ
БАНК РЕШЕНИЙ АРБИТРАЖНЫХ СУДОВ
КАЛЕНДАРЬ СУДЕБНЫХ ЗАСЕДАНИЙ

ПОИСК ПО САЙТУ
  
Количество Статей в теме 'Стратегическое планирование': 601