Спросите у водителя рейсового междугороднего автобуса: «сколько часов добираться в пункт назначения?». В большинстве случаев — услышите тишину, а если не повезет — получите испепеляющий взгляд и привкус бензина будет преследовать вас пару дней как минимум: потому что неизвестно никому, что случится за поворотом :-) То же самое происходит ежедневно в программных проектах — и в ответ на «когда» нужно либо промолчать, либо что-то красиво и уверенно соврать.

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

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

Методика — «от противного»

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

Если разложить известные «риски и чего делать нельзя» на имеющиеся на рынке инструменты управления проектами/командами — можно получить живые и работающие примеры успешной автоматизации — которые, как мы увидим дальше, конечно вместе с работающими в них людьми — ведут нас к успеху, всегда. И даже если ваш программный проект, несмотря ни на что, придет в точку АА, вместо А — это можно будет пережить и распробовать, как победу.

Причины и инструменты

Теперь рассмотрим причины, ведущие к проектным неудачам и подберем соответствующий инструмент, помогающий нам в пути через туман.

«Многабукв»

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

Хранить в почте это не получится — почта предназначена «немного» для другого. Если не верите — готовьтесь читать 200 срочных сообщений в день с утра.

Как спасаться:
— wiki
— Wiki
— WIKI

Т.е. все могут работать с документами онлайн, в достаточно простом формате — и видно, кто и что редактировал и когда и картинки еще вставлять.

Говорят, что еще можно делать совместно документы в Google Docs — но если я не хочу, чтобы документы по моему программному проекту читали и обсуждали с улыбкой и недоумением коллеги из ЦРУ — нужно другое решение, например хранить документы в системе контроля версий и по-очереди работать с ними.

Делаем первую запись: «нужны wiki и хранилище документов»

Где это было и с кем?

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

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

Позволять внешнему поисковику индексировать внутреннюю проектную базу, мягко говоря, опасно. Поэтому поисковик нужен внутренний — а где его взять-то?

В наличии вариантов в opensource не так много:
— sphinx
— solr

Отмечаем: «нужен поисковик по wiki и документам, внутренний».

Я кому-то это поручал…

Не просыпались еще посреди ночи, до смерти напугав стоящего рядом Фредди Крюгера со словами: «я поручил эту задачу кому-то и похоже поставленный срок ее выполнения закончился позавчера – и ты, Фред, в этом виноват!»? Именно — мы нередко даем поручения со сроками и попадаем в капкан «тренера рыжих обезьян» — нужно бегать и напоминать исполнителям о задачах и сроках.

Поэтому нужен инструмент для регистрации задач, исполнителей и сроков выполнения, с напоминалкой на мобильное устройство исполнителю и мне. Как это делается?
— приоритезированный список задач в Excel или Notepad (не всегда удобно, и часто очень неудобно)
— трекер задач (очень нужный инструмент, на рынке их много, но полезных — совсем чуть-чуть)

К полезным трекерам задач я бы отнес инструменты с поддержкой иерархии прав (отделы, подразделения, сотрудники) и бизнес-процессов для каждой задачи, а таких я видел всего 2:
— TrackStudio
— Битрикс24

Конечно есть всем известный и удобный трекер Jira — но так он делать не умеет.

Отмечаем: «нужен трекер задач, лучше с поддержкой иерархии и бизнес-процессов»

Общий мозг

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

Для этой роли прекрасно подходит описанная выше wiki и поиск по ней.

Когда?

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

Тут всем в команде поможет конечно инструмент типа календарь — с возможностью добавлять события, напоминания по событиям (в т.ч. на мобильные устройства и на email). Для менеджеров также конечно был бы полезен инструмент бронирования помещений для проведения в указанный момент времени совещания с командами/клиентами.

Помечаем: «нужен календарь с напоминалкой на мобилу и резервированием сущностей»

Как тебя зовут…

Встречаете обворожительную девушку-программиста в коридоре, вспоминаете иерархию наследования классов и алгоритмы, которые она реализует на этой неделе — но… забыли как ее зовут! Бывало такое? Дальше будет чаще — мозг постепенно стареет, если его не упражнять хрестоматиями по программированию.

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

Помечаем: «нужна иерархия компании с телефонным справочником и поиском».

Страх

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

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

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

Схватить и «замучить»

Коммуникации в проекте настолько важны, что, по секрету, если бы все менеджеры сидели за круглым столом и постоянно общались — проекты бы никогда не заваливались :-) Поэтому важно как можно быстрее обмениваться информацией — но как? По телефону, скайпу… Еще эффективнее — звонить коллеге прямо через браузер, благо это недавно стало возможным благодаря технологиям WebRTC. Ну и конечно — общаться с коллегами в защищенном (т.е. не skype) чате с обменом файлами, голосовыми и групповыми видеозвонками.

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

Коллективный разум

Помним, да, эффект синергии: «2 + 2 = 37». Нередко нужно собираться вместе с другими командами и атаковать проектные риски. Групповая видеоконфа — это хорошо, но часто полезно также общее пространство для обмена информацией — типа рабочих групп, и будет супер — если в эти группы можно будет подключать внешних экспертов.

Отмечаем: «нужно общее рабочее пространство и внешний коннект к нему».

«Точка сборки»

С утра на работе не знаешь с чего начать, кого первым проконтролировать — чтобы к вечеру не завалить чего-нибудь важное. Есть ощущения — что "точка сборки" потеряна и жизнь несется мимо. При этом нужно проверить, что случилось критичного со вчерашнего вечера и прошедшей ночью. Задача — сложно решаемая. Некоторые подписываются на RSS-уведомления, некоторые развивают навыки скорочтения электронной почты… но хочется (и Google когда-то тоже гениально правильно захотелсь реализовать это в виде Google Wave и социальные сети это поняли :-) ) представить этот медиапоток критически важной информации для менеджера в виде живой, редактируемой ленты — с текстами, изображениями, файлами — и чтобы можно было лайкнуть и добавить комментарий.

Отмечаем: «нужна медийная интерактивная живая лента, полезная и менеджеру и разработчику и другому специалисту».

Чеклист

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

Итак, соберем чеклист:

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

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

Всем удачи и успешных программных проектов!

P.S.: опс, пришло напоминание о завтрашней трансляции. Мы работаем в подобной системе внутри компании, если что :-)

Автор: AlexSerbul

Источник