Что нужно сделать при старте нового проекта?

Прочитал статью Титова А.А. «Двадцать основных принципов, без которых нельзя обойтись при создании надёжного программного обеспечения». Появились такие выводы:

1.      Статья носит декларативный, а не процедурный характер.

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

3.      Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.

4.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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

Проектирование интерактивной примерочной. Часть 2

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая оценка

Источники

Ожидания

После выявления целевых групп необходимо составить список их ожиданий. “NASA System Engineering Handbook” такой процесс называет stakeholder expectations definition. Ожидания можно выявить путём опросов представителей целевых групп, например, по следующей методике. Опросы должен проводить не руководитель отдела разработки, а маркетолог.

Для наших целевых групп были выявлены такие ожидания:

Проектирование Интерактивной Примерочной. Часть 1

Как-то на одном из собеседований на должность руководителя отдела разработки мне дали тестовое задание по организации работы над продуктом «Интерактивная Примерочная». Тестовое задание я написал, но обстоятельства сложились так, что я пошёл работать на аналогичную должность в другую компанию.

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

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая Оценка

Источники

Как увеличить количество пользователей социальной сети? Продолжение.

Один мой коллега, ознакомившись со статьёй "Как увеличить количество пользователей социальной сети?", выдвинул ряд тезисов:

1. Предложенное интеграционное решение противоречит тренду. Нынешние социальные сети стараются уйти от приложений вида "всё в одном" и разрабатывают программы, которые отвечают за какую-то узкую функциональность. Например, социальная сети "ВКонтакте" разрабатывает приложение для iPhone, которое будет служить только для обмена сообщениями.
2. Ряд полезных сервисов Skype предоставляет на платной основе. Например, групповая видеосвязь.Нужно просто реализовать эти услуги в новом продукте и предложить их на бесплатной основе.

Приведённые тезисы выглядят убедительно. Тем не менее, они не приведут к решению поставленной задачи. И вот почему...

Как увеличить количество пользователей социальной сети?

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

Задача менеджера продукта – увеличить количество пользователей мессенджера. Для чего? Чтобы увеличить количество пользователей социальной сети.

На собеседовании меня попросили изложить идеи, которые, будучи воплощёнными, могли бы решить поставленную задачу. Я это сделал. Но по каким-то причинам предложенные решения не подошли. Тем не менее, я над ними работал, и мне не хочется, чтобы они пропадали. Поэтому и излагаю для всех желающих.

С чего начать проектирование программы? Часть 1

С чего начать проектирование программы? Классический объектно-ориентированный подход даёт нам однозначный ответ на этот вопрос: с выявления ключевых абстракций и построения объектной модели предметной области.

Джеймс Рамбо, один из создателей языка UML и Rational Unified Process'а, в своей книге "UML 2.0. Объектно-ориентированное моделирование и разработка" предлагает нам такой алгоритм проектирования:

1. Изучить предметную область и выделить классы предметной области.
2. Удалить лишние классы (несущественные или избыточные).
3. Связать классы ассоциациями.
4. Выделить в классах атрибуты.
5. Реструктуризовать классы при помощи наследования.
6. Добавить классы приложения.
7. Добавить операции.

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 218 – 285.

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

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

Общение с заказчиком: переходим на язык задач и проблем

Прежде чем приступать к решению задачи, грамотный проектировщик должен сначала её поставить...

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

Такой перерасход бюджета является серьёзной проблемой, но не катастрофой. Последствия плохой архитектуры могут быть частично скомпенсированы хорошим менеджментом (== грамотным распределением задач) и, наоборот, плохой менеджмент может быть частично скомпенсирован хорошим дизайном. Почему? Потому что хороший дизайн вызывает меньше проблем и, как следствие, уменьшает нагрузку на менеджера.

Более страшной – в плане затрат– является неправильная постановка задачи. Потому что она увеличивает расходы в разы. (Запросто может увеличить бюджет в 2, в 3 и даже в 4 раза.) Здесь я имею в виду ситуацию, когда разработчики делают не то, что клиенту нужно, а реализуют то, что клиент говорит.

Проектирование архитектуры программы: постановка задачи

Первоначально я хотел продемонстрировать, как следует ставить задачи проектирования, на другом примере. Но поскольку на RSDN.RU возникло обсуждение задачи из моего блога, я решил не увеличивать число сущностей сверх необходимого и использовать уже готовый пример. :)

В своём сообщении коллега Undying сформулировал такие требования к кандидату:

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

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