Особенности управления проектами в крупных российских IT компаниях

Рисунок 9. Концептуализация модели барьеров, препятствующих эффективному обмену знаниями

Рассмотрим барьеры, связанные с командой, в контексте улучшения коммуникации в ней.

1. Разнообразие команды. Данный параметр гибких команд является одновременно и их силой, и их слабостью, когда речь заходит о коммуникации. Разный бэграунд участников команды может стать поводом для споров по ряду вопросов. Однако разнообразие несет в себе силу, если правильно его использовать. Внимательное отношение ко мнению всех участников команды и поощрение высказывания любых точек зрения позволит добиться большей эффективности в работе, так как это позволит рассмотреть проблемные вопросы с различных позиций и увидеть картину наиболее полно.

2. Различия в восприятии работы между членами команды также является одной из трудностей коммуникаций. Например, владельцы продукта представляют сторону клиента и не всегда могут объективно оценить ситуацию глазами разработчика, однако эту проблему можно решить, стимулируя всех членов команды делиться своими идеями в ходе ежедневных Scrum-митингов.

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

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

3.2 Стимулирование взаимной поддержки и сплоченности

Исследователями и практиками гибких методологий был разработан ряд экспериментов, применение которых в agile командах может поспособствовать повышению их эффективности. Ниже приведены некоторые из них [33].

Мозговой штурм тестов - этот эксперимент заключается в проведении брейншторминга для определения тестов до начала разработки. В обычном случае, разработчики и тестировщики не взаимодействуют по этому вопросу, что сказывается на уровне взаимной поддержки. Задача состоит в том, чтобы провести первую сессию, где они вместе думают о том, каковы масштабы тестов для истории. Первый сеанс, как правило, не будет последним, поскольку это имеет большое значение.

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

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

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

Развитие новых навыков. Данный эксперимент заключается в изучении членами команды новых для себя областей знаний. Front-end разработчик, например, может изучить базовые особенности back-end разработки, а основы UX/UI дизайна будут полезны для всех членов команды. Обмен знаниями позволит людям стать компетентнее в различных сферах и лучше понимать особенности работы своих коллег, что также положительно скажется на сплоченности команды.

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

Выводы по главе 3

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

Заключение

По результатам написания бакалаврской работы были изучены различные особенности управления IT-проектами, рассмотрена эволюция подходов к управлению их жизненным циклом, послужившая предпосылкой к появлению гибких методологий. Также был проведен сравнительный анализ agile и waterfall, позволивший выявить ключевые преимущества обоих подходов. Кроме того, в качестве релевантной для практического исследования гибкой методологии был подробно рассмотрен Scrum. В ходе теоретической части также было проанализировано влияние различных параметров качества командной работы на успех проекта в сфере информационных технологий.

Практической частью данной работы стал опрос 28 сотрудников компании «Яндекс», применяющих в своей работе гибкие методологии управления проектами. На основании анализа полученных данных с помощью SPSS был сделан вывод о том, что коммуникация и сплоченность являются значимыми предикторами успеха проекта, а сплоченность и взаимная поддержка оказывают существенное влияние на успех команды. Полученные данные оказались согласованными с ранее изученными теоретическими источниками, однако все еще нельзя сказать об их высокой степени достоверности ввиду небольшого объема выборки.

Найденные закономерности могут быть обусловлены ключевым принципом agile, заключающимся в приоритезации людей и их взаимодействий над процессами инструментами. В данном случае эффективная коммуникация становится критически важным фактором, напрямую влияющим на успех проекта, так как документов и регламентов становится значительно меньше. Способность быстро доносить необходимую информацию путем неформальных взаимодействий, а также эффективное проведение Scrum-митингов являются ключевыми аспектами эффективной коммуникации в agile. Кроме того, в самоорганизующихся командах отсутствует строгая иерархия, а потому возрастает важность сплоченности и взаимной поддержки, позволяющей разрешать возникающие конфликты и споры.

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

Таким образом, данное исследование вносит вклад в изучение особенностей управления IT-проектами с помощью гибких методологий и может стать отправной точкой для более подробного анализа данного вопроса в научной литературе.

Список использованной литературы

1. Аншина, М. «Живое» управление проектами. - Управление проектами и программами, №1, 2017.

2. Вольфсон, Б. Гибкие методологии разработки, версия 1.2 (электронная книга), 2012. - 112 с.

3. Расмуссон, Дж. - Гибкое управление IT-проектами. Руководство для настоящих самураев - ООО Издательство «Питер», 2012. - 272 с.

4. Сазерленд, Джефф. Scrum. Революционный метод управления проектами -- Манн, Иванов и Фербер, 2016. -- 288 с.

5. Макконнелл, Стив. Влияние итеративных подходов на предварительные условия // Совершенный код. Питер, 2005. С. 31. -- 896 с.

6. A Guide to the Scrum Body of Knowledge (SBOK™ Guide) - 2016 edition, SCRUMstudy™, a brand of VMEdu, Inc. - 323 с.

7. Barry W. Boehm. «A spiral model of software development: Experience, Principles, and Refinements», Special Report CMU/SEI-2000-SR-008, 2000

8. Dingsшyr, T., Lindsjшrn, Y. Team performance in agile development teams: Findings from 18 focus groups, XP2013, Lecture Notes in Business Information Processing. Vol. 149, 2013, pp. 46-60.

9. Ghobadi, S., Mathiassen, L. Perceived barriers to effective knowledge sharing in agile software teams. Inf. Syst. J. 26 (2), 2016, 95-125.

10. Hoegl, M., Gemuenden, H.G. Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence. Organization Science, Vol. 12, No. 4, 2001, pp. 435-449.

11. Katz. R..The effects of group longevity on project communication and performance. Admin. Sci. Quart. 22, 1982, 81-104.

12. Lakhpanel, B. Understanding the factors influencing the performance of software development groups: An exploratory group-level analysis. Information and Software Technology, Vol. 35, No. 8, 1993, pp. 468-473.

13. Li, Y, Chang, K.C., Chen, H.G., Jiang J. J. Software development team flexibility antecedents. Journal of Systems and Software, Vol. 83, No. 10, 2010, pp. 1726-1734.

14. Lindsjorn, Y., Sjoberg, D. I., Dingsoyr, T., Bergersen, G. R.,& Dyba, T. Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 2016, 274-286.

15. Malone, T.W., Crowston, K.,. The interdisciplinary study of coordination. ACM Computing Surveys, Vol. 26, No. 1, 1994, pp. 87-119.

16. Melo, C.D.O., et al., Interpretative case studies on agile team productivity and management. Information and Software Technology, 2013. 55(2): p. 412-427.

17. Mudrack, P.E. Defining group cohesiveness. A legacy of confusion. Small Group Research, Vol. 20, No. 1, 1989, pp. 37-49.

18. Mullen, B., Copper, C. The relation between group cohesiveness and performance: An integration, Psychological Bulletin, Vol. 115, No. 2, 1994, pp. 210-227.

19. Nerur, S., Mahapatra, R.K., Mangalaraj, G, Challenges of migrating to agile methodologies. Communications of the ACM, Vol. 48, No. 2, 2005.

20. Recker, Jan; Holten, Roland; Hummel, Markus; Rosenkranz, Christoph. How Agile Practices Impact Customer Responsiveness and Development Success: A Field Study. - Project Management Journal, Vol. 48, No. 2, 2017, 99-121.

21. Royce, Winston. Managing the Development of Large Software Systems. - Proceedings, IEEE WESCON, 1970, pages 1-9.

22. Senapathi M., Drury-Grogan M. Refining a model for sustained usage of agile methodologies. - The Journal of Systems and Software 132, 2017, 298-316.

23. Tjosvold, D. Cooperative and competitive goal approach to conflict: Accomplishments and challenges. Applied Psychology, Vol. 47, No. 3, 1998, pp. 285-313.

24. Vinekar, V., Slinkman, C., W., Nerur, S.. Can agile and traditional systems development approaches coexist? An ambidextrous view. Information Systems Management, Vol. 23, No.3, 2006, 31-42.

25. Vinod, V., Dhanalakshmi, J., Sahadev, S.,. Software team skills on software product quality. Asian Journal of Information Technology, Vol. 8, No. 1, 2009, pp. 8-13.

26. 20 самых дорогих компаний Рунета -- 2018. Рейтинг Forbes. . [Электронный ресурс]. URL: http://www.forbes.ru/tehnologii-photogallery/357559-20-samyh-dorogih-kompaniy-runeta-2018-reyting-forbes. (дата обращения: 24.04.2018)

27. Аудитория пользователей интернета в России в 2017 году. [Электронный ресурс]. URL:http://mediascope.net/press/news/744498/ (дата обращения: 24.04.2018)

28. Общая информация о компании Яндекс. [Электронный ресурс]. URL: https://yandex.com/company/general_info/yandex_today/ (дата обращения: 24.04.2018)

29. Поисковые системы в России. [Электронный ресурс]. URL: https://radar.metrika.yandex/ (дата обращения: 24.04.2018)

30. Путевые заметки начинающих Scrum-команд о тупиках. [Электронный ресурс]. URL: https://events.yandex.ru/lib/talks/511/ (дата обращения: 24.04.2018)

31. Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли. [Электронный ресурс]. URL: https://habr.com/company/yandex/blog/207316/ (дата обращения: 24.04.2018)

32. CHAOS Report 2015, The Standish Group International [Электронный ресурс]. URL: http://www.standishgroup.com/ (дата обращения: 24.04.2018)

33. Improving Teamwork Through Experiments. [Электронный ресурс]. URL: https://www.agilesparks.com/blog/improving-teamwork-through-experiments/ (дата обращения: 10.05.2018).

34. Manifesto for Agile Software Development [Электронный ресурс]. URL: http://www.agilemanifesto.org/ (дата обращения: 10.02.2018).

35. Pulse of the Profession 2017, PMI. [Электронный ресурс]. URL: https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf (дата обращения: 25.04.2018)

36. State of agile report. [Электронный ресурс]. URL: https://explore.versionone.com/state-of-agile (дата обращения: 25.04.2018)

37. Survey: Is agile the new norm? [Электронный ресурс]. URL: https://techbeacon.com/survey-agile-new-norm (дата обращения: 25.04.2018)

Приложение. Вопросник.

Общая информация о респонденте.

Сколько человек состоит в вашей команде?

· Менее 5

· 5-10

· 11-20

· 21-40

· Более 40

Какую роль вы выполняете в команде?

· Scrum-мастер

· Владелец продукта

· Член команды (разработчик, тестировщик и тд.)

Ваш опыт работы в сфере IT

· Менее 1 года

· 1-3 года

· 3-5 лет

· Более 5 лет

Ваш опыт работы с Agile

· Менее года

· 1-3 года

· 3-5

· Более 5 лет

Выберите любой проект из тех, что были выполнены с использованием принципов Agile методологий и оцените, насколько вы согласны с высказываниями в отношении командной работы в ходе проекта, а также в отношении его результатов по шкале от 1 до 5, где

1 - Абсолютно не согласен

5 - Полностью согласен

*переменные заносятся с обратным значением.

Размещено на Allbest.ru