В мире IT, где код – это закон, менеджеры проектов играют роль моста между разработчиками и остальным миром. Часто они сталкиваются с вызовами, которые требуют не просто знания Gantt-диаграмм, а понимания кода, который пишут их команды и технических процессов. Но что случается, когда технические навыки менеджера оставляют желать лучшего? Представляем 5 факапов, которые могут разрушить ИТ-проекты в виде новелл.
Новелла первая: Потерянная в терминологии
Аня – молодая и амбициозная проектная менеджерка в небольшой IT-компании, которая специализируется на разработке продуктов для зарубежных рынков. Она известна своей способностью координировать команды и поддерживать отличные отношения с клиентами. Однако ее отсутствие технических знаний часто становится причиной недоразумений.
В ходе одного из проектов, клиент из Германии заказал разработку веб-приложения, которое должно использовать динамические данные из их CRM-системы. Команда разработчиков предложила использовать JavaScript для реализации нужной функциональности, но Аня, путая его с Java, настояла на использовании последней, веря, что это одно и то же.
Разработчики, хоть и удивленные выбором Ани, начали работать с Java. Аня, слышав, что Java – мощный и надежный язык, решила, что он идеально подойдет для проекта, не осознавая, что Java значительно медленнее для целей веб-разработки по сравнению с JavaScript, который предназначен для клиентской части веб-приложений.
Аня, Аня, что же ты наделала…
Когда проект был почти завершен, стало ясно, что продукт значительно медленнее и менее соответствует требованиям клиента, чем ожидалось. Проверка кода выявила, что основная проблема кроется в использовании Java для фронтенда, что является нетипичным и неэффективным решением.
Проект задержался на несколько месяцев, а стоимость его разработки значительно возросла. Аня столкнулась с серьезной критикой со стороны руководства и клиента, что подорвало ее репутацию и самоуверенность. После этого инцидента она поняла, что без глубоких технических знаний невозможно эффективно управлять IT-проектами.
Эта история отражает, как отсутствие понимания базовой технической терминологии может привести к серьезным убыткам и задержкам в проекте. Она подчеркивает важность технических знаний для проектных менеджеров в сфере IT. А получить их можно на курсе Techmind, который разработан именно для проектных менеджеров, работающих в IT.
💡 JavaScript – язык программирования, используемый для создания интерактивных эффектов внутри веб-браузеров, известный своим быстродействием и гибкостью. Java – язык программирования, предназначенный для работы во многих платформах, от серверов до мобильных телефонов, обычно используется для более крупномасштабных и длительных проектов.
Новелла вторая: Когда «хот фикс» становится «холодным душем»
Максим – опытный проектный менеджер в крупной IT-компании, которая работает над разработкой корпоративных систем для международных клиентов. Он всегда стремится к быстрому решению проблем и считает, что может быстро адаптироваться к любым вызовам. Однако его относительное непонимание глубинных технических деталей иногда приводит к ошибкам.
Накануне важной демонстрации продукта для нового клиента, Максим обнаружил незначительную ошибку в интерфейсе, которая могла негативно повлиять на впечатление пользователя. Чтобы быстро исправить это, он предложил разработчикам сделать «хот фикс» без полного цикла тестирования.
Команда разработчиков под давлением от Максима поспешно внесла изменения в код. Максим решил проигнорировать привычный процесс QA и утвердил выпуск обновления, веря, что риск минимален и что все пойдет гладко.
Знал бы ты, Максим, где упадешь
Во время демонстрации, когда клиент проверял функциональность продукта, произошел серьезный сбой. Обновление, внесенное как «хот фикс», повлекло непредвиденные последствия, в результате чего важные части системы перестали функционировать. Это вызвало разочарование у клиента и поставило под сомнение профессионализм компании.
После этого инцидента Максим и его команда вынуждены были провести ряд совещаний для исправления ситуации, что значительно затянуло проект и увеличило его стоимость. Максим понял, что попытка сэкономить время, игнорируя важность процесса тестирования и QA, может привести к серьезным потерям.
Эта история показывает, насколько важно придерживаться установленных процедур и учитывать все технические аспекты перед внесением «хот фиксов». Риск кажется небольшим только на первый взгляд, но его последствия могут быть очень ощутимыми.
💡 Хот фикс (hot fix) – быстрое внесение изменений в живую версию продукта для исправления критических ошибок, обычно минуя стандартные процедуры тестирования и проверки.
Новелла третья: Игнорирование технических долгов
Ирина – проектный менеджер с длительным опытом в международной IT-компании, занимающейся разработкой корпоративного софта. Она зарекомендовала себя как компетентный руководитель, но ее слабое понимание технических деталей иногда приводит к неоправданным решениям.
Проект, который курирует Ирина, начал отставать от графика из-за накопившихся технических долгов, которые не были вовремя решены. Несмотря на предупреждения своих разработчиков о необходимости рефакторинга кода, Ирина решила игнорировать эти рекомендации, считая, что важнее удерживать короткие сроки выпуска продукта.
Вместо исправления основных проблем существующего кода, Ирина настаивала на добавлении новых функций, надеясь удовлетворить требования клиента и улучшить внешние показатели проекта. Это привело к увеличению количества непредвиденных сбоев и снижению общей производительности системы.
Долги нужно платить вовремя
В критический момент, во время презентации продукта важному клиенту, система вышла из строя, обнаружив все накопленные ошибки и недочеты. Ошибки в коде, которые могли быть устранены на ранних этапах, вызвали серьезные сбои, что негативно повлияло на доверие клиента к компании.
Проект претерпел значительные задержки, а компания потеряла потенциальные доходы и пришлось тратить дополнительные ресурсы на безотлагательное решение проблем. Ирина получила серьезное замечание от руководства и поняла значение надлежащего управления техническими аспектами проектов. А если бы прошла Techmind, знала бы, как работать с техническим долгом.
Эта история иллюстрирует, как недооценка технических долгов может привести к фатальным последствиям для проекта и компании в целом. Важно не только придерживаться графиков, но и внимательно относиться к техническому качеству продукта.
💡 Технический долг – это концепция в разработке программного обеспечения, указывающая на отложенное совершенствование кода, которое необходимо выполнить. Игнорирование технического долга может привести к более сложным и дорогим проблемам в будущем.
Новелла четвертая: Оценка времени и ресурсов: «Всегда слишком оптимистично»
Владимир – энергичный и оптимистичный проектный менеджер в стартапе, который занимается разработкой мобильных приложений. Он известен своей способностью быстро запускать проекты и мотивировать свою команду, но его недостаточное понимание технических деталей часто приводит к нереалистичным планам.
Владимир взялся за амбициозный проект разработки новой функциональности для мобильного приложения, которая должна была включать сложную интеграцию с внешними API. Он установил очень агрессивные сроки для завершения проекта, основываясь только на общем обзоре требований и не учитывая технические сложности, озвученные его командой разработчиков.
Под давлением установленных сроков, команда начала работать надежно, но столкнулась с рядом технических вызовов, которые не были учтены Владимиром. Оказалось, что некоторые API, которые должны были интегрироваться, были устаревшими или имели ограниченные возможности, что существенно повлияло на возможности реализации проекта.
Володя, не чуди
По мере приближения дедлайна стало очевидно, что проект не будет завершен в срок. Когда Владимир представил промежуточные результаты инвесторам, они были разочарованы отсутствием значительной части обещанной функциональности.
Проект претерпел задержки, и дополнительные ресурсы были потрачены на перепланировку и дополнительную разработку. Владимир столкнулся с критикой со стороны команды и инвесторов, что подчеркнуло важность точной оценки и планирования на начальных этапах проекта. А если бы он знал, как работать с API, то не попал бы во временную ловушку.
Эта история подчеркивает, как важно для проектных менеджеров иметь реалистичное понимание технических требований и потенциальных вызовов. Оптимизм – хорошее качество, но он должен быть сбалансирован с технической осведомленностью и реалистичным планированием.
💡 API (Application Programming Interface) – это набор правил и спецификаций, по которым различные программные приложения могут взаимодействовать друг с другом. API позволяет разработчикам использовать определенные функции или данные других программ или сервисов, упрощая создание и расширение функциональности своих программ без необходимости разработки всего с нуля.
Новелла пятая – финальная: «Невидимые связи»
Татьяна – опытный проектный менеджер в IT-компании, занимающейся разработкой облачных решений. Она привыкла доверять своей интуиции и опыту, но иногда ее нежелание вдаваться в технические детали приводит к недоразумениям в команде.
Проект, который вела Татьяна, включал интеграцию различных облачных сервисов для создания единой платформы для анализа данных. Татьяна решила пропустить несколько технических встреч, считая, что они лишние, и сконцентрировала свои усилия на управлении графиком проекта.
Отсутствие Татьяны на ключевых обсуждениях привело к тому, что она пропустила важную информацию о несовместимости некоторых сервисов, которые должны были интегрироваться. Это привело к серьезным проблемам с обменом данными между системами, которые уже были частично интегрированы.
Что, трудно на мите появиться?
Когда проект перешел в тестовую фазу, оказалось, что данные не могут эффективно передаваться между различными модулями, что повлекло полный пересмотр подхода к интеграции. Это стало очевидным только тогда, когда клиент начал тестирование и столкнулся с многочисленными ошибками в отчетах.
Проект испытал значительные задержки, и Татьяна была вынуждена объяснить причину этих проблем. Компания потратила значительные ресурсы на исправление ошибок, что не только увеличило расходы, но и подорвало доверие клиента к компании.
Эта история подчеркивает важность участия проектного менеджера в технических обсуждениях, даже если они кажутся рутинными или лишними. Важно обеспечить, что все аспекты проекта взаимодействуют гармонично, и невидимые связи между компонентами не перерастают в непредвиденные проблемы.
Эпилог
Все эти истории, конечно, вымышлены. Или нет. Возможно, именно вы узнали себя в них. Возможно, это наши студенты до обучения на Techmind, поделились своим опытом. Не позволяйте таким факапам стать частью вашего IT-проекта. Более 3200 выпускников уже получили Tech Skills на курсе TechMind и теперь используют эти навыки для управления IT-проектами, разговаривая на одном языке с разработчиками. Запишитесь на курс сегодня и станьте менеджером, который ведет проекты к успеху, а не к фиаско.