Шесть причин, по которым ваш IT-проект будет провален

Шесть причин, по которым ваш IT-проект будет провален

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

В случае если люди, реализующие IT-проект, не слышат друг друга – ищи ветра в поле. Согласие критично принципиально важно на всех уровнях и этапах: и между клиентами / разработчиками, и в взаимодействующих команд. Каких неприятностей, которые связаны с антропогенным причиной, принципиально важно избежать, автоматизируя бизнес? Чек-лист от специалистов: Алексея Абрамова (на фото слева), в различные годы трудившегося начальником IT-проектов в компаниях «Элемент», SODIS Lab, «Ростелеком», и Михаила Серякова (справа), обладателя компании «Вебтолк» из Абакана.

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

1. Отсутствие компетенции

Алексей Абрамов: Я неоднократно встречал клиентов, каковые видят в ответе для автоматизации работы универсальную «чудесную кнопку» и пробуют с его помощью устранить множество неприятностей, каковые к IT никакого отношения не имеют. Несложный пример: не организован замысел развития компании, не обрисованы бизнес-процессы, нет регламентов, не очерчены KPI, нет понимания мотивации. В общем, не готов фундамент, имеется системные неточности.

И с для того чтобы старта компания собирается внедрить CRM, электронный документооборот либо что-то второе.

Михаил Серяков: Самая громадная неприятность появляется, в то время, когда клиент считает, что он компетентен и вмешивается в движение работ, практически не владея нужными навыками, опытом и методологиями. Позднее в собственных разочарованиях он обвинит разработчика, постарается переложить на него ответственность.

2. Недоверие

М.С.: Наиболее значимый вопрос: может ли клиент делегировать? В случае если нет, таковой обладатель проекта не упрощает и не активизирует работу, а практически стопорит ее. Замыкая все вопросы на себя, он не дает возможности ничего сделать ни своим сотрудникам, ни тем более – внешним подрядчикам.

Это значительная неприятность, время от времени фатальная.

3. Неорганизованность

А.А.: Простое дело — загруженность IT-экспертов смежными проектами. Но начальник проекта, программист либо консультант — не автомобили, они не смогут мгновенно переключаться с одного проекта на другой. В следствии фактически неизбежны переработки и срывы сроков.

Героизм в режиме 24/7 видится в IT-проектах часто. Но позван он в большинстве случаев не большим уровнем ответственности, а значительными проблемами в планировании. Принципиально важно избегать чрезмерно оптимистичных сроков исполнения работ и больше времени посвящать тому, дабы договориться «на берегу». направляться обрисовать функциональные требования, создать техзадание, прописать роли и ответственность сторон.

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

Необходимо понимать, что сотрудничество на IT-проектах – не абстракция. В случае если обе стороны готовы обсуждать сложные моменты, совместно корректировать замыслы – тогда шансы на успех увеличиваются. А в одиночку спасти проект тяжело и клиенту, и разработчику.

М.С.: Работу IT-компаний довольно часто дезорганизует излишняя «клиенториентированность»: клиент неизменно прав, несложнее дать согласие, чем спорить. сроки и Бюджеты клиенты довольно часто «отжимают досуха», и в случае если у разработчика не достаточно настойчивости и смелости этому противостоять, проиграют в итоге обе стороны.

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

А обычный грех программистов – исполнение поставленной задачи «по-своему». Получается, что формально ТЗ выполнено, но с отличиями. Время от времени это не имеет значение, время от времени критично.

Как противостоять всем этим проблемам? Клиенту направляться предоставлять разработчику больше дополнительной информации: создавать графические прототипы, составлять пользовательские сценарии. Но всего заблаговременно не учесть, исходя из этого лучше применять эластичные методики.

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

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

4. Гордыня

А.А.: Разработчики довольно часто грешат тем, что пробуют защищать свою точку зрения до утраты пульса. Звучит это так: «Мы лучшие на рынке, у нас лучшие практики, лучшие продукты, все лучшее». Апеллируя к собственному громадному IT-опыту, они часто игнорируют либо поверхностно трактуют опыт клиентов в предметной области. Прямое следствие: разработчики пробуют навязать подход и сервис, что удачнее IT-компании, чем клиенту.

не меньше страшна обстановка, в то время, когда разработчики готовы дать согласие со всем, что диктует клиент: только бы заплатил.

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

Но такая непрофильная деятельность редко оправдана: это изобретение велосипеда, расходы и лишние риски.

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

5. Саботаж

М.С.: Проект может намеренно тормозить один из сотрудников компании-клиента. Это возможно один из управленцев, что собирался отдать его второму подрядчику, но не сумел. В случае если проект провалится, он постоянно сможет сообщить: «Напрасно меня не послушали».

Это возможно важный менеджер, которому выгодно «слить» проект, что ему лично невыгоден, поскольку додаёт ему работы и обязанностей.

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

6. Незаинтересованность

А.А.: Демотивированные сотрудники — это по большому счету не «айтишная» неприятность. Но особенность IT-проектов в том, что на их успех должны быть мотивированы и люди из компании-подрядчика, и люди со стороны клиента. В случае если этого нет, то виноваты не рядовые сотрудники, а их начальники. Я сам начальник, и замечательно это осознаю.

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

М.С.: В случае если проект идет из-под палки, без личной включенности – это кроме того не антропогенный фактор, а «нечеловеческий». При таких условиях сотрудники клиента видят в разработчиках не партнеров по неспециализированному делу, а вредителей, каковые пришли их отвлечь от ответственных дел, дабы все ухудшить. Не редкость, что сотрудники клиента по большому счету не знают о замыслах по внедрению IT-продукта.

При таких условиях возможности проекта, само собой разумеется, плачевные.

Что делать?

А.А.: Клиентам стоит осознавать, что IT-решения не ликвидируют их системные неприятности. А их внедрение – это не вопрос цены и не вопрос сроков. IT может лишь улучшить (автоматизировать, оптимизировать) то, что уже имеется.

Исходя из этого необходимо трезво оценивать настоящее состояние собственного бизнеса, а не обманывать самих себя, пробуя позже свалить вину на поставщиков IT-решения.

М.С.: Подрядчикам направляться искать не «самое не сильный звено», а место, где задачи накапливаются и не решаются. И необходимо выяснять, из-за чего так происходит. Нас, к примеру, во внутренних проектах выручает канбан-доска. Скоро узнается, что менеджеры тормозят с приемкой задач, что программисты перегружены, что управление очевидно не успевает принимать решения.

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

Мастерство управления IT-проектами Питер 2014 Скотт Беркун Release it! дизайн и Проектирование ПО для тех, кому не все равно Питер 2016 Майкл Нейгард Executive Market671 0

Поделитесь своим опытом разработчика либо клиента с аудиторией Executive.ru

IT-менеджмент2609 12

Из-за чего разработка вебмагазина преобразовывается в муку?

>

Это"Без шуток" Предсказания "2017-2018" Ванги и Нострадамуса совпадают.Что ожидает мир повергает в кошмар.


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer