Нравится нам это или нет, если мы не занимаемся хобби-проектом только для собственного удовольствия, даже самые технические из нас на самом деле являются просто менеджерами проектов, которые умеют писать код. И, как менеджер проекта, мы можем испытать душераздирающий провал проекта.
Есть много способов, которыми проект может потерпеть неудачу. Он может потерпеть неудачу, потому что сроки не соблюдаются, бюджеты превышены, результаты не соответствуют требованиям и т. Д. Но это также может привести к эмоциональным сбоям; проект может быть успешным, но ожидания людей не оправдываются, и нет никакого чувства удовлетворения или «хорошо выполненной работы».
Итак, что вы можете сделать как технический менеджер проекта, чтобы минимизировать ваши шансы добавить «лидера провалившегося проекта» в ваше резюме? Ответ: в значительной степени то, что делают лидеры нетехнических проектов.
Управляйте ожиданиями
Приятно думать, что реальность важна, но все в деловом мире знают, что то, что люди думают, что произошло, всегда важнее, чем то, что действительно произошло, и то же самое относится и к проектам. Даже некоторые из наиболее успешных проектов могут пострадать от несоответствия ожиданий, которые навсегда затмевают проделанную хорошую работу и полученные выгоды. И если провал ожиданий достаточно серьезен, это может даже подорвать и сорвать другие проекты, которые делали хорошо. Так как вы управляете ожиданиями?
Во-первых, убедитесь, что все четко понимают, что будет делать проект, какие будут выгоды, что потребуется от пользователей, какие ресурсы необходимы для его поддержки, от каких других проектов он может зависеть, и что он собирается делать. Я знаю, что перечислил этот последний пункт дважды, но это действительно важно! Много раз пользователи слышат то, что они хотят услышать, и может потребоваться больше, чем просто напоминание или быстрый разговор, чтобы все исправить.
Будьте особенно внимательны к тому, что высшее руководство говорит о проекте, как прямо из ворот, так и позже, по мере продвижения проекта, и действуйте быстро, чтобы исправить любые ложные заявления, сделанные до того, как они могут стать принятой мудростью и «частью масштаб проекта с самого начала ».
В то же время, действуйте так же быстро и вежливо, чтобы справиться с любым негативным разговором, который вы слышите о проекте. Идея состоит не в том, чтобы подавить мятежный разговор (хотя получение списка имен — неплохая идея, знаете ли, на потом), а в том, чтобы выяснить, является ли это недопониманием, неправильным изложением фактов или это то, что может превратиться в проблему позже и должна быть решена незамедлительно, либо путем изменения спецификаций проекта, либо по-другому взглянуть на основные предположения.
Не будь традиционным, будь итеративным
В традиционном проекте типа водопада вы разрабатываете план проекта, который начинается в начале и продолжается до конца и заканчивается общей оценкой времени и долларов. Не делай этого. Вместо этого используйте итеративную, гибкую модель проекта, где каждый шаг заканчивается легко тестируемым, хорошо видимым продуктом, с которым люди могут оценить свои ожидания.
Несмотря на сходство, технические проекты не похожи на строительство моста. Основными неизвестными для строительства моста являются характеристики почвы, в которые вы закладываете основу. Как только это оценено, большая часть неопределенности устранена. У технических проектов может не быть больше переменных, но они распространяются в течение всего жизненного цикла проекта, и вы никогда не дойдете до сути, пока не закончите (возможно), где все эти переменные известны. Водопад основан на том факте, что неизвестные будут оценены и получат компенсацию за его прохождение. По разным причинам технические проекты, похоже, не работают таким образом, и водопад — плохая модель.
Основная проблема с водопадом, однако, заключается в том, что он работает, чтобы сфокусировать людей на какой-то почти завершающей стадии «тестирования». Он не предназначен для поддержки ситуаций, когда тестирование начинается почти в первый день. В результате проблемы, даже основные, не будут выявлены, пока проект не будет в значительной степени завершен.
Agile, с другой стороны, полностью посвящен итерации: работайте в течение двух недель, создайте что-то реальное и попросите пользователей проверить это, а затем повторите. Там нет презентаций Power Point или команд марафонцев, просто люди могут войти и поиграть. Это то, что привлекает их внимание, разве вы не знаете.
Пока вы занимаетесь Agile, я бы также предложил использовать Scrum. Их не нужно делать вместе, но я думаю, что это хорошая идея. Вы знаете, что нравится людям? Им нравятся короткие вещи; это начинается, это происходит, все кончено. Взрыва. В этом и заключается суть Scrum — частые, очень короткие, не время для удобных или начальных встреч, встречи проектной команды, где мы говорим о Турции и говорим быстро. Это мешает любому забыть о проекте и о том, что он делает, и не отнимает смехотворное количество времени от их дня.
И что все это делает для вас? Agile и Scrum позволяют намного лучше понять, как вы оцениваете общую оценку проекта. При регулярном серьезном тестировании пользователей вы получаете информацию о том, что, возможно, придется добавить в приложение, и о том, что можно извлечь. Если есть серьезные проблемы, вы можете начать редизайн очень рано в процессе. Это делает вас более активным, что похоже на красивые волосы; он всегда приносит дивиденды и ставит проект в позитивном свете.
Зло Сфера Creep
Больше проектов обречено на ползучесть, чем что-либо еще. Сфера охвата проекта приводит к опозданию проектов, превышению бюджета и неспособности удовлетворить субъективные ожидания гостевой аудитории. Так что не позволяй этому случиться. Как будто я наслаждаюсь временем с твоими родственниками, я знаю, что это легче сказать, чем сделать.
В своей наиболее распространенной форме смещение области видимости происходит, когда кто-то поднимает точку и вводит ее словами «но это было так, как мы хотели с самого начала». И они, вероятно, честны; они, возможно, искренне думали, что функция X будет выполнять функцию Y, и это на самом деле было главной причиной существования проекта. И так, поскольку он должен был быть в приложении с самого начала, вы добавляете его. Иногда это не имеет значения, но в большинстве случаев это не так. И это может произойти не один раз в жизненном цикле проекта, но это может происходить снова и снова. Ну так что ты делаешь?
Во-первых, все остальное, вы должны быть дипломатичным. Возможно, вам захочется перепрыгнуть через стол и схватить кого-то за горло, вы должны сохранять спокойствие и сохранять равновесие сил на своей стороне. Вернитесь к своему первоначальному утверждению проекта и покажите, что запрос никогда не обсуждался, а тем более идентифицирован как неотъемлемая часть приложения (вот где очень четкое и подробное изложение проекта имеет решающее значение).
Во-вторых, чтобы ограничить число случаев возникновения ползучести, вы должны убедиться, что ваши пользователи хорошо выполняют свою работу итеративного тестирования. Ползучесть области является наиболее разрушительной, когда она происходит позже в процессе разработки, когда необходимо сделать много модификаций, которые более или менее невидимы для пользователя. Итеративное тестирование, а не просто разговор о том, как идет работа над проектом, является гораздо лучшим способом объяснить пользователю, что именно делает система.
В конечном счете, проблема двоякая. Во-первых, вы, возможно, не были достаточно подробны или конкретны с точки зрения того, что приложение будет и не будет делать; Обе стороны должны быть прописаны. Во-вторых, вы должны иметь в виду, что ваши пользователи, вероятно, не уделяют 100% внимания, когда вы разговариваете или читаете что-то, что вы написали (даже когда они на собрании с конкретной целью выяснить, что приложение должно делать) , Не ожидайте этого, потому что вы четко изложили вещи, которые люди будут знать. Хорошая методика заключается в том, чтобы изложить ваш план, а затем попросить их рассказать, что, по их мнению, будет делать система и чего они могут от нее ожидать. Запишите сеанс — вы можете использовать его на испытании.
К сожалению, нет никакого лекарства для предотвращения ползучести прицела. Лучшее, что вы можете сделать, — это попытаться предотвратить это, и когда оно поднимает свою уродливую голову, постарайтесь отогнать это как можно лучше. В конце концов, есть хороший шанс, что вам придется делать то, что хочет ваш пользователь, но не просто делать это; сделать это дополнение к вашему проекту. Укажите шаги, необходимые для этого, время, которое это займет, влияние, которое будет иметь на все остальное, а затем получите подтверждение от вашей пользовательской базы, что они действительно этого хотят.
Остерегайтесь странных вещей
Остерегайтесь странных вещей. Я не имею в виду странные требования, но вещи, которые могут быть новыми для вашей команды или вашей среды. Например, если вы создаете приложение, которое принимает данные кредитных карт, вы действительно понимаете PCI ? Или, может быть, вы собираетесь перейти с CodeIgniter на Lavarel. Вам понадобится дополнительное время (даже за пределами обычной кривой). Следите за вещами, которые могут сбить вас с толку.
Резюме
Суть в том, что управление проектами — это игра, в которую нельзя выиграть. Если вы попадаете под бюджет и время, все будут думать, что вы просто мешочек с песком и больше не будете верить вашим оценкам. Следите за тем, что важно. Будьте конкретны, будьте добры, будьте проворны и надейтесь на лучшее.
Изображение через Fotolia