Прожект-менеджмент в софтостроении: кодировать или писать требования?
Как Вы может быть помните, с января этого года я веду стартап со скромным названием "Пульт управления страной". Сейчас, когда один прототип Пульта уже отправлен в мусорную корзину, а второй готовится к презентации активной части широкой публики, я хочу немного пофилософствовать о том, как же правильно управлять разработкой таких в достаточной степени необычных программных продуктов.
Начну с собственных "криков души". За последние двадцать лет я прочел несколько умных книг по проектированию программ, и думал, что в общих чертах представляю себе, как это правильно делается. Пишутся требования, проектируется архитектура (структуры данных и интерфейсы), затем делается эскизный проект и так далее, и тому подобное. Так вот, я даже не могу передать словами, насколько это представление оказалась опасным заблуждением!
Подход "от требований к реализации" оправдан в тех случаях, когда команда делает очередную версию уже известного продукта, например, очередную клиент-серверную информационную систему предприятия. Но в ситуации, когда разрабатывается нечго принципиально новое - мы не можем знать требований, не поработав с программой! Ну то есть конечно, мы можем врать себе, что "знаем как надо", и "отлично представляем, как это будет работать"... но между "отлично представляем" и тем, как оно выглядит на практике, лежит пропасть. И потому чем более подробные требования будут написаны на первом этапе, и чем более крутые архитектурные решения на них будут приняты - тем больше проблем возникнет сразу же после появления первого прототипа. Потому как работать он будет, и даже делать примерно то же, что хотелось - но вот хотели-то мы первоначально совсем не того, чего надо было хотеть!
Начиная по-настоящему новый продукт, мы не просто не знаем, что он должен будет делать. Мы знаем это неправильно. А потому - "Кто еще скажет про разработку архитектуры перед прототипами - к стенке!". Таков мой первый наскоро выстраданный принцип инновационного прожект-менеджмента.
Второй принцип связан с популярным в последнее время "рефакторингом", и звучит так: "Не рефакторить отстой, рефакторить понравившийся продукт". До получения практического опыта у меня существовала иллюзия, что рефакторинг улучшает потребительские свойства программного продукта. Так вот, ничего подобного. Причесывание кода, перетасовка классов, и даже оптимизация отдельных методов не в силах изменить ситуацию "беда, что скучен твой роман". Выручить может только создание новой функциональности, то есть по-сути - переписывание кода заново. Вот когда прототип "цепляет" - тогда его имеет смысл рефакторить. Иначе - напрасно потраченное время.
И наконец, третий принцип, который уже успел до меня изложить gaperton:
- ...Влад. Дай я скажу, - спокойно говорит Тол, - Я старше тебя, и наблюдал за свою жизнь много "архитекторов" и "дизайнеров", которые не пишут код. Влад, они очень быстро становятся очень полохими архитекторами и дизайнерами. Год или два - и все.
- Правда?
- Точно. Они довольно быстро теряют связь с реальностью. Когда ты не пишешь код, ты не получаешь обратной связи, ты не видишь, во что выливаются на практике твои мысли. Когда ты не правишь багов, и не сидишь на поддержке, ты лишаешь себя важнейшего элемента обратной связи - ты не видишь, какие решения оказались плохи, а какие хороши. А обратная связь - это сама суть инженерии.
Я столкнулся с этим эффектом с другой стороны. В ходе нашей разработки неоднократно возникали споры о том, как реализовывать ту или иную функцию. Когда обсуждался конкретный код, они обычно заканчивались решением "поменять здесь", "а здесь оставить до следующей версии". Но когда речь заходила о требованиях или того хуже об архитектуре (форматах данных, способах реализации и т.д.) - вот тут накал дискуссий доходил до драматических высот, а сухим остатком была лишь взаимная неудовлетворенность коллег друг другом.
Все дело в том, что код однозначно интерпретируется внешней по отношению к разработчикам реальностью (средой исполнения), а вот словесные формулировки каждый норовит толковать по-своему. Отсюда один шаг до старой идеи "код - лучшая документация"; но можно сделать и второй шаг. Написание кода, конечно же, требует затрат времени; но ведь время, проведенное в словесных баталиях, тратится столь же необратимо! Так может быть, имеет смысл перейти от написания требований на естественном языке к их макетированию на языке программирования?!
Такие вот мысли возникли у меня после полугода плавания по морю софтостроения. Посмотрим, что будет дальше :)
Начну с собственных "криков души". За последние двадцать лет я прочел несколько умных книг по проектированию программ, и думал, что в общих чертах представляю себе, как это правильно делается. Пишутся требования, проектируется архитектура (структуры данных и интерфейсы), затем делается эскизный проект и так далее, и тому подобное. Так вот, я даже не могу передать словами, насколько это представление оказалась опасным заблуждением!
Подход "от требований к реализации" оправдан в тех случаях, когда команда делает очередную версию уже известного продукта, например, очередную клиент-серверную информационную систему предприятия. Но в ситуации, когда разрабатывается нечго принципиально новое - мы не можем знать требований, не поработав с программой! Ну то есть конечно, мы можем врать себе, что "знаем как надо", и "отлично представляем, как это будет работать"... но между "отлично представляем" и тем, как оно выглядит на практике, лежит пропасть. И потому чем более подробные требования будут написаны на первом этапе, и чем более крутые архитектурные решения на них будут приняты - тем больше проблем возникнет сразу же после появления первого прототипа. Потому как работать он будет, и даже делать примерно то же, что хотелось - но вот хотели-то мы первоначально совсем не того, чего надо было хотеть!
Начиная по-настоящему новый продукт, мы не просто не знаем, что он должен будет делать. Мы знаем это неправильно. А потому - "Кто еще скажет про разработку архитектуры перед прототипами - к стенке!". Таков мой первый наскоро выстраданный принцип инновационного прожект-менеджмента.
Второй принцип связан с популярным в последнее время "рефакторингом", и звучит так: "Не рефакторить отстой, рефакторить понравившийся продукт". До получения практического опыта у меня существовала иллюзия, что рефакторинг улучшает потребительские свойства программного продукта. Так вот, ничего подобного. Причесывание кода, перетасовка классов, и даже оптимизация отдельных методов не в силах изменить ситуацию "беда, что скучен твой роман". Выручить может только создание новой функциональности, то есть по-сути - переписывание кода заново. Вот когда прототип "цепляет" - тогда его имеет смысл рефакторить. Иначе - напрасно потраченное время.
И наконец, третий принцип, который уже успел до меня изложить gaperton:
- ...Влад. Дай я скажу, - спокойно говорит Тол, - Я старше тебя, и наблюдал за свою жизнь много "архитекторов" и "дизайнеров", которые не пишут код. Влад, они очень быстро становятся очень полохими архитекторами и дизайнерами. Год или два - и все.
- Правда?
- Точно. Они довольно быстро теряют связь с реальностью. Когда ты не пишешь код, ты не получаешь обратной связи, ты не видишь, во что выливаются на практике твои мысли. Когда ты не правишь багов, и не сидишь на поддержке, ты лишаешь себя важнейшего элемента обратной связи - ты не видишь, какие решения оказались плохи, а какие хороши. А обратная связь - это сама суть инженерии.
Я столкнулся с этим эффектом с другой стороны. В ходе нашей разработки неоднократно возникали споры о том, как реализовывать ту или иную функцию. Когда обсуждался конкретный код, они обычно заканчивались решением "поменять здесь", "а здесь оставить до следующей версии". Но когда речь заходила о требованиях или того хуже об архитектуре (форматах данных, способах реализации и т.д.) - вот тут накал дискуссий доходил до драматических высот, а сухим остатком была лишь взаимная неудовлетворенность коллег друг другом.
Все дело в том, что код однозначно интерпретируется внешней по отношению к разработчикам реальностью (средой исполнения), а вот словесные формулировки каждый норовит толковать по-своему. Отсюда один шаг до старой идеи "код - лучшая документация"; но можно сделать и второй шаг. Написание кода, конечно же, требует затрат времени; но ведь время, проведенное в словесных баталиях, тратится столь же необратимо! Так может быть, имеет смысл перейти от написания требований на естественном языке к их макетированию на языке программирования?!
Такие вот мысли возникли у меня после полугода плавания по морю софтостроения. Посмотрим, что будет дальше :)