1452
правки
Изменения
Нет описания правки
===Бизнес-модель===
===Эффективность===
Моя главная задача - эффективность использования всех ресурсов для получения максимальной отдачи для бизнеса наших клиентов на каждый потраченный рубль. Для этого я применяю все возможные подходы. Постараюсь здесь их описать.
====Команда====
Для эффективной работы команда должна быть компактной. Оптимальный размер команды для разработки ПО - 7-15 человек. Это тот объем, который позволяет руководителю дотянуться до каждого сотрудника, проконтролировать работу, объединить усилия всех сотрудников в единый организм и комплексно, целенаправленно решать стратегические задачи. Понятно, что написать Windows с такой командой невозможно, ее нужно сильно расширять. Однако это требует существенного расширения управленческого аппарата. К сожалению, речь идет не только о найме проект-менеджера на каждую группу по 7 человек (зарплаты которых измеряются сотнями тысяч рублей), но и раздутии штата прочими сотрудниками, напрямую в процессе разработки/сопровождения не занятыми, поскольку работу групп нужно координировать, большую задачу нужно разбить на блоки, требования, функциональность, методы тестирования, интерфейсы взаимодействия которых нужно полностью задокументировать. Объем технической документации при "правильном" подходе занимает больше времени и стоит дороже, чем сам процесс разработки. После разработки каждого куска его надо тестировать отдельными штатными единицами, а потом пытаться склеить эти блоки вместе. В случае же с компактной командой ее можно просто собрать вместе, и сказать: "Давайте сделаем вот это. Ты делаешь это, а ты - вон то, через 2 дня собираемся вместе и проверяем".
====Задачи====
====Экстремальное программирование====
В своей работе в разной степени мы используем принципы [https://ru.wikipedia.org/wiki/Экстремальное_программирование экстремального программирования]. Мое самое любимое положение из него - код должен максимально быстро начинать приносить реальную пользу (прибыль!) нашим клиентам. При классическом подходе к разработке, как я уже писал, сначала пишется документация всей доработки, потом разбивается на подзадачи, реализуется, тестируется, отлаживается и т.д., на все это уходит куча времени и денег. Потом ее пытаются сдать заказчику, и тут оказывается, что задачу изначально не совсем так поняли. Чтобы этого всего избежать, мы сходу пишем небольшие куски, и сразу, даже без тестирования, отдаем заказчику. Да, при этом могут быть ошибки. Но заказчик сразу начинает пользоваться, решать свои бизнес-задачи, т.е. экономить деньги. Ошибки, замечания, пожелания, которые он обнаруживает уже в промышленной эксплуатации, а на на примере [https://ru.wikipedia.org/wiki/Научный_юмор#Сферический_конь_в_вакууме сферических коней в вакууме], как это делает тестировщик, в реальном времени передаются разработчикам и так же быстро устраняются. В результате мы получаем огромный прирост эффективности - в разы, если не на порядки. С одной стороны сильно сокращаются издержки на документирование, тестирование, случаи решения несуществующих задач, а с другой стороны - клиент получает самую свежую функциональность со скоростью горячих пирожков и сразу начинает на этом зарабатывать. Пусть эта функциональность и не обязательно полная или надежная - это лучше, чем ничего.
====Коммуникация====
====Бюрократия====
====Поддержка====
====Эволюция====
==Отказ от ответственности==
==Что входит в покупку (аренду) системы==
