Чистка проекта или операция “Выбрасываем хлам”
29 марта, 2008
Осмотритесь вокруг. Сколько вокруг вас вещей? Не ленимся, поворачиваем голову налево, поворачиваем голову направо.
Десятка два любой более менее обеспеченный человек насчитает, не занимаясь точной арифметикой. Сколько из этих вещей вам действительно необходимы, сколько вещей из списка необходимых вы использовали в последние два месяца? Я из 30 насчитал не больше десятка.
Рассмотрим молодого человека, который совсем недавно попал во взрослую жизнь. Для чистоты примера у него нет богатых родителей и других “нечестных” доходов со стороны .
Первая работа - появились хоть и не большие, но деньги. Что покупают большинство студентов с подработок? Например, телефон за 400-500$. Молодой человек почувствовал многократно выросший статус в своем кругу общения. С этого момента включается потребительская культура, зачастую неконтролируемая, начинается культ владения вещами. Покупаются нужные и не очень предметы быта, одежды и прочие вещи. Полезно ли это для него? Каждый ответит для себя сам.
Наступает такой момент, когда уже вещи выпадают из всех шкафов и ящиков. Ровно в этот момент человек задает себе вопрос “Что с этим делать?”, и начинает раскладывать по полочкам, в стопочки, по ящикам. Проблема “решена”. В кавычках, потому что через короткий промежуток времени вещи уже не помещаются в стопки. Сколько ваших знакомых застряли на этой стадии?
Возникает ровно такой же вопрос, но вместо него лучше задать себе вопрос “Зачем мне это ВСЕ?”. Начинается чистка, сначала выбрасывается все старое, потом, через некоторое время, все ненужное (пусть и совсем новое). Важное условие для настоящего решения проблемы - задавать нужные вопросы. Лучше рано, чем поздно.
Вам знаком принцип самоподобия? Если нет, то открываем новый таб, спрашиваем у гугла и читаем. Прочитали? Теперь вернемся к теме…
Посмотрим на путь менеджера проектов.
Есть определенные знания, опыта мало. Менеджер и команда развивают проект: разработчики множат всякие “вещи” в архитектуре и коде, менеджер применяет все подряд подходы и методики. Часть “вещей” полезна, часть - откровенный хлам. Разница между материальным (вещевым) хламом и проектным лишь в том, что в проекте намного меньше места. Когда количество хлама достигает критической точки, проект тормозит, команда задается ровно таким же вопросом, что и молодой человек выше - “что с этим делать?”. Разработчики узнают про паттерны проектирования, менеджер - про методологии. Вот здесь и включается потребительская культура.
Разработчики тянут в проект все архитектурные красивости - , менеджер тянет в проект все, что входит в выбранную методологию. Разница между проектным хламом и вещевым лишь в том, что в первом случае команда весь хлам таскает с собой, куда бы она ни двигалась. Представьте RUP для команды в 5 человек. Страшно? :) А сколько знакомых программистов увлекаются строительством ради строительства? Кстати на этом этапе разработчики страшно боятся GOTO
Проект в ступоре. Здесь два пути.
1. Команда в очередной раз задается вопросом “Что делать?” и….ничего не делает, потому что сделать ничего нельзя. Ежики плакали, кололись, но продолжали есть кактус. Смею предположить, что каждый, хотя бы раз, наблюдал такой проект.
2. Команда задается вопросом “Зачем нам это ВСЕ?”. Разработчики начинают перепроектирование, менеджер начинает все раскладывать “по полочкам”. В проекте появляется “свободное пространство” от выброшенного хлама. Проект снова живет.
Причем здесь самоподобие? А притом, что законы потребления действуют одинаково хорошо как для отдельно взятого человека, так и для команды.
Для компаний действуют точно такие же законы, посмотрите на названия CMMI уровней. Яркий пример некотроллируемого потребления - внедрение инструментов, а не оптимизация бизнес-процессов. Вроде бы и приобретение сделали, а лучше не стало, зато можно будет хвастаться перед друзьями партнерами. Получаем ситуацию, когда на каждого программиста по 2 начальника. Все знают, где эта компания будет через пару лет, пусть и с замечательным инструментарием?
Не забываем задавать себе вопрос при покупке/внедрении “Зачем нам это?” и давать на него честный ответ. Не обманывайте себя
Спасибо за внимание.
PS. Все чистое имхо.
8 комментариев на “Чистка проекта или операция “Выбрасываем хлам””
Мое мнение:
Вы должны войти прежде чем комментировать.


марта 31, 2008 в 9:19
+пицот аффтар жж0т, пиши исчо!
марта 31, 2008 в 9:39
Shagrat, это похвала или сарказм?
марта 31, 2008 в 9:40
очень хороший пост *побежала разребать проекты*
марта 31, 2008 в 10:57
Похвала, фигли:))
июня 27, 2008 в 0:24
>Разработчики тянут в проект все архитектурные красивости
это, кстати, как ? если архитектура выбрана удачно, то туда уже ничего лишнего не привнесёшь при всём желании. а если нет - то это уже не красивости, это уже как-то по-другому называется
июня 27, 2008 в 0:25
>А сколько знакомых программистов увлекаются строительством ради строительства?
кстати, сколько ? я бы таких взял на заметку - с целью перевербовать к себе в группу
июня 27, 2008 в 8:13
отвечу одним коментом
>если архитектура выбрана удачно, то туда уже ничего >лишнего не привнесёшь при всём желании.
Да ну? Прикрутить пару финтов сомнительной полезности всегда можно. А ведь все это время. Но это уже вопрос желания, возможность всегда найдется.
>а если нет - то это уже не красивости, это уже как->то по-другому называется
Интересно, а много людей делают анализ затрат времени и усилий против потенциальных возможностей, прежде чем вносить исменения в архитектуру (считай пару и более месяцев рефакторинга для достаточно крупного проекта)? По честному интересно…
Если архитектура позволяет реализовать все требования заказчика и время на реализацию функциональности с существующей архитектурой меньше чем с новой, то зачем перестраивать проект? Если же хочется все-таки улучшить архитектуру, то делать это в начале проекта/итерации. Если такого времени нет - надо давать втык ПМу.
имхо, ПО должно решать поставленные задачи и проблемы, чем скорее оно выйдет, тем быстрее начнет приносить пользу. И если из-за какого архитектурного изыска (читай рюшечка, без которой все вполне обходится) проект стопорнет на месяц два в лучшем случае.
> кстати, сколько ? я бы таких взял на заметку - с >целью перевербовать к себе в группу.
Есть парочка:) Но нужен опытный тимлид, чтоб вовремя срывал стоп-кран у “строителей”

А раз уж коснулись, то да, лучше брать в команду строителей, чем бездарей, вторых как грязи, а вот из первых вполне бриллиант может получиться, главное правильно обтесать и отшлифовать
июля 23, 2008 в 12:14
Интересный пост. В плане работы над проектом использую методологию “все гениальное - просто”. Так как я работаю еще с Ruby on Rails то там один из основных принципов работы “ваша задача, не чьи-то паттерны”.
В плане вещей всё сложнее