Юрий Ветров. Управление проектами и проектирование интерфейсов

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

Читайте продолжение истории →

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

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

Читайте продолжение истории →

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

Читайте продолжение истории →

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

Фрилансеры — один из самых доступных и частых способов закрыть фронт работ, который в компании выполняются нерегулярно. Либо в случае, если свои люди беспросветно заняты на других проектах, а нанимать новых нет смысла или времени. Я работаю с фрилансерами по обоим причинам. Хотя за последнее время потерянные сроки и нервы убедили, что время и смысл для поиска постоянных сотрудников лучше все-таки найти. А субподрядчиков использовать только для совсем уж нетипичных работ.

Читайте продолжение истории →

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

Читайте продолжение истории →

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

Читайте продолжение истории →

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

Читайте продолжение истории →

Несовпадение реального хода проекта с планом — стандартная ситуация. Тут весь вопрос в том, насколько оно значительно. Хорошо, если заложенные вначале риски покрывают разницу между фактом и планом. Терпимо, если ценой повышения КПД — за счет сверхурочных или подключением новых людей — можно нагнать упущенное. Хуже, если срок сдачи на носу, а процент выполнения где-то наполовине пути. Бывают, конечно, и совсем клинические ситуации. Но лучше делать так, чтобы в них не оказываться.

Читайте продолжение истории →