Битва закончена, люди много говорят о том, какой методикой они руководствовались, когда принимали свои решения, но вообще-то всегда бывает чертовски много того, к чему приходят на ощупь.
Адмирал Ф.Д.Флетчер
Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.
Кроме этого, как и любого другого разработчика, меня несколько беспокоит перспектива отрасли на ближайший десяток лет, так как это связано с моими профессиональными перспективами. И, просто как человеку, хочется испытать свое понимание вещей на прочность, понять насколько локален опыт и выводы из него.
Речь пойдет о достаточно простых вещах, но я неоднократно замечал, что в научных исследованиях прогресс или тупик возникает, когда простая и очевидная вещь оказывается не тем, чем она кажется, или дефект в программе внезапно обнаруживается в модуле, который “не может” содержать ошибку.
(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)
Сложно отрицать, но на программное обеспечение вот уже уже тридцать с лишним лет влияет одновременно и болезнь и благословение роста рынка. Когда рынок растет не нужно быть эффективным. Когда ты приносишь туземцам зеркальца и колокольчики, их мало волнует качество, они в них не разбираются, но они это хотят.
Да, случались тревожные звонки вроде кризиса 2000-х, когда распад самых чудовищно неэффективных высокотехнологичных компаний и сгорание инвестиций в перегретый рынок пошатнули экономику. Внезапно выяснилось, что IT компаниям было бы неплохо приносить прибыль хотя бы в отдаленной перспективе. Качество продуктов и их полезность немного выросли, случился очередной приток потребителей и инвестиций. И эта мысль опять ушла на второй план.
Если я работаю технологом или методологом при производстве зеркалец и колокольчиков для папуасов, то для меня нет смысла быть эффективным. Фактор роста подтвердит почти любые мои решения как правильные, а хорошая политика продаж и вовсе замнет то, что сам продукт является проблемным. Зеркальца могут быть расколотыми, почти ничего не отражать и не звенеть, но они будут продаваться, особенно хорошо они пойдут у тех, кто не видел других зеркал и если начал действовать фактор “хочу как у него”. Ему подвержены не только отдельные люди, Хотим модернизироваться, потому что все внедряют ERP или CRM, или открывать интернет-направление только потому, что все это делают. Почему-то такое поведение не кажется мне удивительным.
За это же время возникло большое количество методик разработки программного обеспечения и его оценки.
В теории, благодаря им из хаоса возникает порядок, весь продукт красиво раскладывается на характеристики, функционал, архитектурные особенности и т.д. А создание разбивается на вполне конечное количество процессов, подающихся унификации и измерению. Классно, красиво, и похоже на точную науку.
У меня есть два градусника, один старый ртутный, другой новый электронный. Я хочу узнать температуру своего тела, чтобы понять, не заболеваю ли я. Я беру старый градусник и он через 5 минут показывает мне своим ртутным столбиком что-то вроде 37,2 градуса. Потом беру новый, красивый и безопасный градусник, жму кнопочку, он пикает и через минуту показывает мне 36,638 градуса. Какой из градусников вы отправите на свалку?
Большинство отправит старый, потому что он медленно работает, выглядит замызганным и по нему можно узнать меньше цифр после запятой, что не имеет никакого отношения к точности измерения и, соответственно, прогноза заболею ли я. Да и в конце концов он стоил больше денег, выбрасывать жаль.
Подобная точность — лишь иллюзия, ориентированная на увеличения доверия. Методики разработки и оценки ПО хотят выглядеть научными, потому что это делает их солиднее и, это можно дороже продать. Время специалиста, который их использует, тоже начинает оцениваться дороже.
Да, это дает понимание того, как увеличить бюджеты и объем рабочих мест, но какое это отношение имеет к заявленным целям любой методологии, а именно: Уменьшение объема и стоимости работы, необходимого для создания определенного программного продукта или изменении существующего до определенного состояния.
Что такое “состояние продукта” — это отдельный вопрос и я предпочту пока его не затрагивать, так как это касается в первую очередь требований и методик измерения к которым есть много вопросов.
Целей много, и эта формулировка при хотя бы небольшом расширении, так или иначе покажется противоречивой для заказчика, разработчика или руководителя, находящегося между ними.
Если я разработчик, то хочу от методики помощи в том, чтобы делать мою работу как можно лучше. Как можно реже повторять код. Как можно реже пускать целые модули под нож и переписку с нуля. Быть уверенным, что определенная часть кода будет работать корректно при большинстве условий. Быстро искать дефекты. Быстро подключать к процессу разработки нового сотрудника.
С точки зрения бизнеса важно другое — извлечение прибыли из разницы в стоимости работ и бюджета проекта. Предсказуемость процесса и расходов. Юридическая обтекаемость требований к продукту. Привязка к этапам финансирования и календарным периодам. Формирование зависимости клиента от поддержки продукта и выхода новых версий.
Каждый из списков можно продолжить по своему желанию. Но это две разные планеты, кое-где цели совпадают, часто противоречат друг-другу, часто находятся в разных измерениях. Адаптировать методику тестирования продукта к квартальным периодам?! А это, вообще, как?
Иногда все сводится к нахождению компромисса. Я хочу иметь качественный код без дефектов, но хочу сдать проект в обозначенный срок. Ни одна из методик не разрешит это противоречие, оптимум зависит от конкретного случая. Наверное не получится сдать продукт, содержащий критические дефекты, какие бы сроки не стояли. И не получится потратить полдесятка лет на математическое обоснование корректности кода. (хотя, как ни странно бывает и так и так). Или, как было отмечено одним хорошим специалистом, общая задача существования компьютера — это упрощение повторяемых и рутинных операций. С точки зрения бизнеса, если они приносят ему прибыль, они выгодны.
Основная проблем в том, что претендуя на покрытие как можно больше целей все существующие методики прошли крайне мягкую проверку на эффективность. Наше ПО как-то работает и продается? Потом мы смогли собрать новую версию и тоже как-то ее продать? Наверное, у нас прекрасные методики, раз мы способны на столь значимые достижения.
Я открываю браузер и предполагается, что существует большое количество компаний, которые сформировали лицо того, что я в нем вижу. Неа, на самом деле это лицо формирует то, что сотня человек открыли браузер в первый раз пока вы читали этот абзац, остальное относится к деталям.
Постепенно и неравномерно для разных областей, но рынок ПО станет ближе к насыщению и рваться начнет там, где тонко. Систематические провалы определенных типов проектов скорее всего будут приводить к провалу и смене целых парадигм. Наверное, самые крупные из них касаются представлений об отрасли и управлении проектами внутри нее.
В следующих заметках я хочу рассмотреть, откуда к нам пришли методики и особенности управления и разобраться, что с ними не так.
Разработка ПО: 2. Наследство
Разработка ПО: 3. Теплое и мягкое
Адмирал Ф.Д.Флетчер
Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.
Кроме этого, как и любого другого разработчика, меня несколько беспокоит перспектива отрасли на ближайший десяток лет, так как это связано с моими профессиональными перспективами. И, просто как человеку, хочется испытать свое понимание вещей на прочность, понять насколько локален опыт и выводы из него.
Речь пойдет о достаточно простых вещах, но я неоднократно замечал, что в научных исследованиях прогресс или тупик возникает, когда простая и очевидная вещь оказывается не тем, чем она кажется, или дефект в программе внезапно обнаруживается в модуле, который “не может” содержать ошибку.
(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)
1. Индустрия на стероидах
Сложно отрицать, но на программное обеспечение вот уже уже тридцать с лишним лет влияет одновременно и болезнь и благословение роста рынка. Когда рынок растет не нужно быть эффективным. Когда ты приносишь туземцам зеркальца и колокольчики, их мало волнует качество, они в них не разбираются, но они это хотят.
Да, случались тревожные звонки вроде кризиса 2000-х, когда распад самых чудовищно неэффективных высокотехнологичных компаний и сгорание инвестиций в перегретый рынок пошатнули экономику. Внезапно выяснилось, что IT компаниям было бы неплохо приносить прибыль хотя бы в отдаленной перспективе. Качество продуктов и их полезность немного выросли, случился очередной приток потребителей и инвестиций. И эта мысль опять ушла на второй план.
Если я работаю технологом или методологом при производстве зеркалец и колокольчиков для папуасов, то для меня нет смысла быть эффективным. Фактор роста подтвердит почти любые мои решения как правильные, а хорошая политика продаж и вовсе замнет то, что сам продукт является проблемным. Зеркальца могут быть расколотыми, почти ничего не отражать и не звенеть, но они будут продаваться, особенно хорошо они пойдут у тех, кто не видел других зеркал и если начал действовать фактор “хочу как у него”. Ему подвержены не только отдельные люди, Хотим модернизироваться, потому что все внедряют ERP или CRM, или открывать интернет-направление только потому, что все это делают. Почему-то такое поведение не кажется мне удивительным.
За это же время возникло большое количество методик разработки программного обеспечения и его оценки.
В теории, благодаря им из хаоса возникает порядок, весь продукт красиво раскладывается на характеристики, функционал, архитектурные особенности и т.д. А создание разбивается на вполне конечное количество процессов, подающихся унификации и измерению. Классно, красиво, и похоже на точную науку.
У меня есть два градусника, один старый ртутный, другой новый электронный. Я хочу узнать температуру своего тела, чтобы понять, не заболеваю ли я. Я беру старый градусник и он через 5 минут показывает мне своим ртутным столбиком что-то вроде 37,2 градуса. Потом беру новый, красивый и безопасный градусник, жму кнопочку, он пикает и через минуту показывает мне 36,638 градуса. Какой из градусников вы отправите на свалку?
Большинство отправит старый, потому что он медленно работает, выглядит замызганным и по нему можно узнать меньше цифр после запятой, что не имеет никакого отношения к точности измерения и, соответственно, прогноза заболею ли я. Да и в конце концов он стоил больше денег, выбрасывать жаль.
Подобная точность — лишь иллюзия, ориентированная на увеличения доверия. Методики разработки и оценки ПО хотят выглядеть научными, потому что это делает их солиднее и, это можно дороже продать. Время специалиста, который их использует, тоже начинает оцениваться дороже.
Да, это дает понимание того, как увеличить бюджеты и объем рабочих мест, но какое это отношение имеет к заявленным целям любой методологии, а именно: Уменьшение объема и стоимости работы, необходимого для создания определенного программного продукта или изменении существующего до определенного состояния.
Что такое “состояние продукта” — это отдельный вопрос и я предпочту пока его не затрагивать, так как это касается в первую очередь требований и методик измерения к которым есть много вопросов.
Целей много, и эта формулировка при хотя бы небольшом расширении, так или иначе покажется противоречивой для заказчика, разработчика или руководителя, находящегося между ними.
Если я разработчик, то хочу от методики помощи в том, чтобы делать мою работу как можно лучше. Как можно реже повторять код. Как можно реже пускать целые модули под нож и переписку с нуля. Быть уверенным, что определенная часть кода будет работать корректно при большинстве условий. Быстро искать дефекты. Быстро подключать к процессу разработки нового сотрудника.
С точки зрения бизнеса важно другое — извлечение прибыли из разницы в стоимости работ и бюджета проекта. Предсказуемость процесса и расходов. Юридическая обтекаемость требований к продукту. Привязка к этапам финансирования и календарным периодам. Формирование зависимости клиента от поддержки продукта и выхода новых версий.
Каждый из списков можно продолжить по своему желанию. Но это две разные планеты, кое-где цели совпадают, часто противоречат друг-другу, часто находятся в разных измерениях. Адаптировать методику тестирования продукта к квартальным периодам?! А это, вообще, как?
Иногда все сводится к нахождению компромисса. Я хочу иметь качественный код без дефектов, но хочу сдать проект в обозначенный срок. Ни одна из методик не разрешит это противоречие, оптимум зависит от конкретного случая. Наверное не получится сдать продукт, содержащий критические дефекты, какие бы сроки не стояли. И не получится потратить полдесятка лет на математическое обоснование корректности кода. (хотя, как ни странно бывает и так и так). Или, как было отмечено одним хорошим специалистом, общая задача существования компьютера — это упрощение повторяемых и рутинных операций. С точки зрения бизнеса, если они приносят ему прибыль, они выгодны.
Основная проблем в том, что претендуя на покрытие как можно больше целей все существующие методики прошли крайне мягкую проверку на эффективность. Наше ПО как-то работает и продается? Потом мы смогли собрать новую версию и тоже как-то ее продать? Наверное, у нас прекрасные методики, раз мы способны на столь значимые достижения.
Я открываю браузер и предполагается, что существует большое количество компаний, которые сформировали лицо того, что я в нем вижу. Неа, на самом деле это лицо формирует то, что сотня человек открыли браузер в первый раз пока вы читали этот абзац, остальное относится к деталям.
Постепенно и неравномерно для разных областей, но рынок ПО станет ближе к насыщению и рваться начнет там, где тонко. Систематические провалы определенных типов проектов скорее всего будут приводить к провалу и смене целых парадигм. Наверное, самые крупные из них касаются представлений об отрасли и управлении проектами внутри нее.
В следующих заметках я хочу рассмотреть, откуда к нам пришли методики и особенности управления и разобраться, что с ними не так.
Разработка ПО: 2. Наследство
Разработка ПО: 3. Теплое и мягкое
