• 07.06.2006Компетенции в компании-разработчике
Какие классы специалистов будут в нашей компании наиболее востребованными через полгода? Сколько у нас есть людей, способных написать веб-интерфейс к системе Х? А сколько из них сейчас доступно? Но самый главный вопрос - действительно ли эти люди способны написать требуемый веб-интерфейс? Ресурсное планирование, прогнозы загрузки, гарантия качества, оценка при найме - вот для чего нужно в компании-разработчике ПО такое понятие, как "компетенция". • Автор: Публикация компании SEADMEX <
• 22.05.2006Российский и западный IT менеджмент вчера и сегодня
Так уж получилось, что за пока еще достаточно небольшое время пребывания в современной IT-тусовке, мне удалось поработать и приходящим разработчиком или консультантом на дюжину больших и не очень, наших и зарубежных IT компаний. Своими наблюдениями я делюсь с читателями моего блога и, надеюсь, кому-нибудь эта информация будет полезна. • Автор: Гайдар Магдануров <
• 10.05.2006Словарь ненормативной лексики руководителя
Этот небольшой словарик является иллюстрацией к «Правилам-2». Здесь собраны типовые высказывания руководителей и/или хозяев компании, которые при настойчивом их повторении приводят к трудностям в управлении проектом и персоналом. • Автор: Игорь Ашманов <
• 04.05.2006Словарь ненормативной лексики программиста
Этот небольшой словарик - приложение к статье «Правила Ашманова». Там я говорю об особенностях управления программистами, а здесь собрал «практический материал» - высказывания, которые менеджер не должен понимать буквально. опробуйте узнать в них реальные ситуации из жизни своего проекта. • Автор: Игорь Ашманов <
• 26.04.2006Заметки о быстрой разработке с использованием Scrum
В отличие от традиционных подходов к управлению разработкой ПО, включающие в себя детальные планы, диаграммы, расписания, тестовые спецификации и прочие документы, которые с избытком научились производить менеджеры проектов еще до того, как проект начался, Scrum предлагает вести проект своим оптимальным курсом, раскрывая все технические подробности уже в ходе этого пути. • Автор: Вячеслав Дукальский <
• 18.04.2006Правила Ашманова. Часть 2: об управлении проектами
При росте объема проектов и количества используемых человеческих ресурсов управление ими становится похоже на сложную инженерную задачу (которая сама по себе становится проектом - более высокого уровня). Для управления большими проектами нужны знание общей теории, детальные бизнес-процедуры, мощные программные средства управления проектами, высококвалифицированные специалисты по управлению. • Автор: Игорь Ашманов <
• 17.04.2006Правила Ашманова (Управление проектами)
Данный свод высказываний предназначен для руководителей, которым пришлось заниматься новым для себя делом - управлять тем или иным "программистским" проектом (созданием информационной системы предприятия, разработкой сайта, и т.п.). Много раз видели мы срыв сроков, провал проектов и бизнесменов, с готовностью вкладывавших деньги в новую технологию, поражающую воображение. • Автор: Игорь Ашманов <
• 05.04.2006Управление конфигурацией и изменениями: RUP или ITIL?
При разработке нередко срываются графики и превышается бюджет, а созданное программное обеспечение не отвечает требованиям, к нему предъявляемым. Зачастую это обусловлено недостаточными прозрачностью, контролем, трассировкой и мониторингом, а усугубляется неконтролируемыми изменениями. Что использовать: RUP или ITIL? • Автор: Лапыгин Дмитрий, Александр Новичков <
• 27.03.2006Оценка возврата инвестиций от внедрения процесса управления конфигурациями
Оценка возврата инвестиций от внедрения процесса управления конфигурациями Любой долгосрочный проект, связанный с разработкой программного обеспечения, разрастается из-за изменения требований заказчиков и конечных пользователей создаваемого продукта. В результате такой проект становится трудноуправляемым • Автор: КомпьютерПресс <
• 20.03.2006Оценка возврата инвестиций от внедрения процесса управления конфигурациями
Любой долгосрочный проект, связанный с разработкой программного обеспечения, разрастается из-за изменения требований заказчиков и конечных пользователей создаваемого продукта. В результате такой проект становится трудно управляемым. Руководство компании разработчика оказывается не в состоянии контролировать деятельность подчиненных и не имеет четкого представления о качестве выпускаемого изделия.. • Автор: КомпьютерПресс <
