Вам нужен герой: менеджер проекта

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

Зачем вам нужен менеджер проектов в первую очередь

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

Что касается меня, то я программирую уже 13 лет, и даже сейчас в какой-то момент каждый проект уводит меня в неизведанную территорию. Существует так много различных технологий, и новые методы разрабатываются с такой пугающей скоростью, что я никогда не чувствую, что полностью разбираюсь в том, что происходит. Хотя у каждого проекта есть свои уникальные проблемы, есть некоторые константы:

• У проекта цейтнот.
• Бюджет меньше, чем хотелось бы.
• Я дороже, чем клиент хотел бы.
• Я слушаю не так идеально, как хотелось бы клиенту.
• Клиент не объясняет вещи так хорошо, как хотелось бы.

Очевидно, нам нужна няня. Кто-то должен вмешаться, чтобы установить основные правила, сохранить честность всех и убедиться, что мы не забыли ничего важного. Кто-то должен облегчить общение между всеми сторонами.

Этот кто-то, этот герой, менеджер проекта.

Когда я начал писать эту статью, Toptal не предлагал контракты с менеджерами проектов, но они предлагают сейчас. Синергия! Я могу только представить, что сильные мира сего прочли следующие советы и поняли, что упускают прекрасную возможность.

Почему программист не может стать хорошим менеджером проекта

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

Видит бог, вы платите нам достаточно, поэтому кажется разумным ожидать, что мы сможем справиться сами, а не заставлять вас платить за чужое время, верно?

Ну, во-первых, вы платите нам за код.

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

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

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

Почему из клиента не получится хороший руководитель проекта

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

У вас, однако, тоже много дел.

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

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

Возьмем, к примеру, обеспечение качества (QA). Надлежащее обеспечение качества необходимо для получения того, что вы хотите от любого проекта, и оно никогда не получает того внимания, которого заслуживает. Хороший руководитель проекта максимально использует ограниченные ресурсы QA, а также гарантирует качество ваших программистов. Иногда мы выходим из своей глубины, а иногда делаем ошибки. Вам нужен технически подкованный человек на руководящей должности, чтобы определить, просто ли у вашего программиста выходной, или он или она на самом деле плохо подходит для проекта. Раннее решение кадровых проблем может означать для вашего проекта разницу между жизнью и смертью.

Наконец, даже вам, клиенту, иногда нужна небольшая проверка и/или баланс. Мне трудно это писать, так как мы, программисты, не очень известны своим откровенным характером. Достаточно сказать, что я работал над многими проектами, где клиент был непреклонен в том, что все было главным и абсолютно все, что нужно было сделать. Хотя я не сомневаюсь, что это была абсолютная правда, эти клиенты, к сожалению, не могли контролировать количество часов в сутках. Они не получили того положительного результата, которого хотели и/или заслуживали, и я чувствую, что этого результата можно было бы избежать, если бы клиент доверил менеджеру проекта полномочия оценивать объем работы и тактично, но твердо контролировать ситуацию. . Трудно выносить беспристрастные суждения, которые требуются для большинства технических проектов, когда на кону стоит ваша идея и ваши деньги, а компьютеру все равно, плачем ли вы или я или кричим над ним. (Я знаю, что это правда, потому что я пробовал это много раз.)

Неполный список методов управления техническим проектом

Если вы решили проигнорировать предыдущие 1000 с чем-то слов и управлять своим проектом самостоятельно, или вы собираетесь нанять кого-то, но хотите быть более осведомленным о процессе, этот список поможет вам. Я никогда (официально) не был менеджером проекта, поэтому я не могу сказать, какие инструменты будет использовать тот или иной менеджер проекта, но я добился хорошего успеха со всеми этими методами:

Вехи

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

Оценки времени

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

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

Истории пользователей

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

Для получения краткой информации о пользовательских историях я нашел эти учебные пособия от Mountain Goat Software и Романа Пихлера, которые были качественными и краткими. Для получения дополнительной информации обо всей философии гибкого управления проектами, попробуйте этот пост в блоге Toptal The Ultimate Introduction to Agile Project Management Пола Барнса.

Композиции (Мокапы)

Это не статья о том, зачем вам нужен дизайнер, потому что я чувствую, что большинство клиентов уже это понимают, но это стоит повторить, потому что вы увидите огромный прирост производительности, если представите перед своими программистами конкретный, хорошо продуманный дизайн. Каждый раз, когда нам нужно принять проектное решение, нам приходится выходить из «зоны», и каждый раз, когда нам приходится возвращаться и что-то менять, потому что нам не предоставили окончательный вариант, ну, сами посчитайте… Я не жалуюсь, потому что дизайн — это весело, но, по моему опыту, это источник № 1 дополнительных оплачиваемых часов, которых можно избежать.

Большинство дизайнеров создают композиции, также известные как композиции, в Adobe Photoshop, Adobe Illustrator или Sketch. Если вы делаете это самостоятельно, вы можете использовать один из бесчисленных онлайн-инструментов, таких как Balsamiq или InVision. Композиция не обязательно должна иметь те же цвета и стили, что и готовый продукт (поскольку их можно легко изменить позже), но, пожалуйста, потратьте дополнительное время, чтобы убедиться, что все элементы пользовательского интерфейса присутствуют и учтены.

Стенд-ап встречи

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

Во время стендапа все ходят по кругу, чтобы предоставить краткий отчет о состоянии, информируя всех членов команды о прогрессе друг друга. Вы можете узнать больше о стендапах на сайте ExtremeProgramming.Org. Если вы все работаете удаленно и не хотите, чтобы все общались по Skype каждый день, вы можете попробовать такой забавный инструмент, как 15Five, в качестве альтернативы стендапам. 15Five позволяет членам команды вносить свой вклад, когда им это удобно, и предлагает им вопросы для опроса, чтобы получить более подробные ответы.

Билетная система

Хотя любой может поддерживать систему заметок и Google Docs (где все задачи выделены разными цветами), на самом деле в этом нет необходимости; многие люди пытались решить эту проблему для вас. Basecamp и Trello славятся своей простотой использования, в то время как Pivotal пытается упаковать всю «гибкую» философию в очень удобный пакет. Что бы вы ни выбрали, хорошая система продажи билетов позволит вам, как минимум:

• Создание задач
• Назначение приоритета и срока выполнения
• Связать задачи и подзадачи
• Назначьте различные разрешения, такие как «завершено» или «неудачное тестирование».
• Показать все задачи, назначенные определенному пользователю

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

Управления источником

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

Большинство современных проектов используют Git, хотя иногда вы столкнетесь с Subversion (SVN) при работе над проектами, которые существуют уже некоторое время. Github позволяет бесплатно размещать неограниченное количество общедоступных репозиториев (плюс, он содержит большинство мировых проектов с открытым исходным кодом), в то время как Bitbucket позволяет размещать неограниченное количество частных репозиториев и поэтому является предпочтительным выбором для коммерческих проектов.

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

Контроль источника самый лучший.

Разработка через тестирование

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

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

Заворачивать

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