Ежели постараться, можно и за пять
Nov. 3rd, 2014 12:02 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kaipaАлёша: Степан, у гостя карета сломалась
Степан: Вижу, барин. Ось полетела и спицы менять надо.
Алёша: За сколько сделаешь?
Степан: За день сделаю.
Алёша: А за два?
Степан: Ну, за два... Сделаем и за два.
Алёша: А за пять дней?
Степан: Ну, ежели постараться, можно и за пять.
Алёша: А за десять?
Степан: Ну, барин, ты задачки ставишь! За десять дней одному не справиться, помощник нужен. (С)
Как передать проект (простенький) от одного человека к другому, немного его улучшив? На днях в нашей компании была попытка (вроде бы успешно пресеченная) сделать это классическим анекдотическим способом:
- Разбить проект на 6 частей, и поручить каждую отдельному человеку, который раньше о проекте ничего не знал, кроме названия
- В некоторых особо простых случаях, поручить часть двум людям
- Добавить двух генераторов спецификаций от бизнеса
- Добавить двух инженерных менеджеров
- Добавить продукт-менеджера
В общей сложности по плану должно было быть задействовано девять человек, а если добавить того, кто придумал эту гениальную схему, то все десять.
В этой связи придумал эмпирическое правило: время разработки прямо пропорционально числу участников (обычно).
Сейчас напишу несколько очевидных вещей, которые можно не читать.
Вообще, разработка ПО -- это достаточно сложная творческая работа. Одна из возможных интерпретаций того, что собой представляет программа (или программный комплекс) -- это математическая модель некоторого процесса или процессов. Роль программиста в таком случае сродни физику, который строит математическую модель физического явления на основе теорий и экспериментальных данных. Основная сложность в том, что за исключением простых случаев или космоса: 1) полного понимания (спецификации) моделируемой области не бывает; 2) способов, которым процесс может быть приблизительно запрограммирован (точно, в отсутствии формальной спецификации невозможно), бесконечно много. Из этого возникает принципиальная сложность предсказать: 1) насколько точно программа будет делать то, что предполагается; 2) сколько времени (а значит, и денег) займет разработка.
Программиста эти сложности обычно не пугают, потому что они внешние к тому, чем он занимается. Но пугают менеджеров, заказчиков и т.п, в общем тех, кому важны определенные ответы на вопросы "сколько" и "когда". Вот эти несчастные люди (сами, или другие по их просьбе) придумывают всевозможные формальные процессы разработки, основные цель которых -- прозрачность, прогнозируемость, снижение рисков. Достигается это разными способами: добавлением бюрократии, введением новых ролей (то есть разбиением общей задачи на подзадачи по типам деятельности, а надежде, что оценить более узкую подзадачу проще), построением эффективной двусторонней связи заказчик-разрабочик и др. В любом случае, деятельность программиста встраивается в некоторую формальную структуру, которая по идее и должна отвечать на вопросы "сколько" и "когда".
Суть работы самого программиста от этого мало меняется, но время разработки естественно вырастает в разы. Зато прогнозируемо.
P.S. Лучшая книга о разработке ПО (психологии, организации и т.п.) -- "Мифический человеко-месяц" Брукса. Ей уже почти 30 лет, но основные идеи вечны. Кто не читал, не пожалеете.
Степан: Вижу, барин. Ось полетела и спицы менять надо.
Алёша: За сколько сделаешь?
Степан: За день сделаю.
Алёша: А за два?
Степан: Ну, за два... Сделаем и за два.
Алёша: А за пять дней?
Степан: Ну, ежели постараться, можно и за пять.
Алёша: А за десять?
Степан: Ну, барин, ты задачки ставишь! За десять дней одному не справиться, помощник нужен. (С)
Как передать проект (простенький) от одного человека к другому, немного его улучшив? На днях в нашей компании была попытка (вроде бы успешно пресеченная) сделать это классическим анекдотическим способом:
- Разбить проект на 6 частей, и поручить каждую отдельному человеку, который раньше о проекте ничего не знал, кроме названия
- В некоторых особо простых случаях, поручить часть двум людям
- Добавить двух генераторов спецификаций от бизнеса
- Добавить двух инженерных менеджеров
- Добавить продукт-менеджера
В общей сложности по плану должно было быть задействовано девять человек, а если добавить того, кто придумал эту гениальную схему, то все десять.
В этой связи придумал эмпирическое правило: время разработки прямо пропорционально числу участников (обычно).
Сейчас напишу несколько очевидных вещей, которые можно не читать.
Вообще, разработка ПО -- это достаточно сложная творческая работа. Одна из возможных интерпретаций того, что собой представляет программа (или программный комплекс) -- это математическая модель некоторого процесса или процессов. Роль программиста в таком случае сродни физику, который строит математическую модель физического явления на основе теорий и экспериментальных данных. Основная сложность в том, что за исключением простых случаев или космоса: 1) полного понимания (спецификации) моделируемой области не бывает; 2) способов, которым процесс может быть приблизительно запрограммирован (точно, в отсутствии формальной спецификации невозможно), бесконечно много. Из этого возникает принципиальная сложность предсказать: 1) насколько точно программа будет делать то, что предполагается; 2) сколько времени (а значит, и денег) займет разработка.
Программиста эти сложности обычно не пугают, потому что они внешние к тому, чем он занимается. Но пугают менеджеров, заказчиков и т.п, в общем тех, кому важны определенные ответы на вопросы "сколько" и "когда". Вот эти несчастные люди (сами, или другие по их просьбе) придумывают всевозможные формальные процессы разработки, основные цель которых -- прозрачность, прогнозируемость, снижение рисков. Достигается это разными способами: добавлением бюрократии, введением новых ролей (то есть разбиением общей задачи на подзадачи по типам деятельности, а надежде, что оценить более узкую подзадачу проще), построением эффективной двусторонней связи заказчик-разрабочик и др. В любом случае, деятельность программиста встраивается в некоторую формальную структуру, которая по идее и должна отвечать на вопросы "сколько" и "когда".
Суть работы самого программиста от этого мало меняется, но время разработки естественно вырастает в разы. Зато прогнозируемо.
P.S. Лучшая книга о разработке ПО (психологии, организации и т.п.) -- "Мифический человеко-месяц" Брукса. Ей уже почти 30 лет, но основные идеи вечны. Кто не читал, не пожалеете.
