Дайджест "Как создается программное обеспечение?"

Всем привет. Меня зовут Дмитрий Раденко, основатель сообщества SaaS Founders. Помогаю фаундерам IT-компаний находить новых крупных клиентов с помощью лидогенерации в LinkedIn. Сегодня мы поговорим о том, как создается программное обеспечение. И в мире разработки программного обеспечения часто возникают разногласия относительно того, как лучше всего создавать программное обеспечение и как управлять проектами. И эти разногласия часто возникают из-за различных предположений о самой природе программного обеспечения. Если мы разберемся о том, что такое программное обеспечение, какие фундаментальные аспекты лежат в основе его функционирования и создания, нам будет гораздо проще понимать ограничения и делать тот софт, который нужен людям и который способен развиваться. Давайте сегодня рассмотрим триаду взаимосвязанных факторов, которые лучше всего объясняют природу программного обеспечения и его сложности. Итак, первый фактор — так называемое предельное состояние программного обеспечения. Что это значит? Дело в том, что равное обеспечение занимает уникальную позицию между физическим миром, в котором есть жесткие ограничения, рост, вес, скорость и так далее, и миром фантазии, где возможно всё. С одной стороны, конечно, программное обеспечение ограничено физическими характеристиками хардвера, аппаратного обеспечения, на котором оно разворачивается, объем памяти, скорость процессоров и так далее. С другой стороны, разработчики имеют огромную свободу в создании виртуальных миров и логики, которая не ограничена физическими законами. Однако, чтобы сделать программное обеспечение управляемым и полезным, разработчики вводят многочисленные мягкие ограничения. И эти ограничения часто являются произвольными и могут вызывать разногласия. Например, решение ограничить программу приемом только одного входного файла. Или предположение, что человек может иметь только один электронный адрес. Они являются мягкими ограничениями, которые упрощают разработку, но при этом могут не соответствовать всем реальным сценариям использования данного софта. Важно понимать, что многие ограничения, которые кажутся жесткими, на самом деле таковыми не являются и просто являются исторически обусловленными мягкими ограничениями. Ну, например, Структура операционных систем, основанная на принципах Unix или использование ESC как языка межпрограммного взаимодействия, является результатом исторического развития, а не неизбежной необходимостью. То есть люди договорились, что давайте компоненты будут такими, и они будут взаимодействовать между собой определенным образом. Исходя из того видения, исходя из тех задач, которые перед ними стояли. Насколько это актуально сейчас и насколько подобные ограничения являются жесткими, это большой вопрос. Следующая проблема. Проблема циркулярной спецификации. Что это значит? Дело в том, что часто компании не могут полностью определить, какое именно программное обеспечение они хотят создать, пока не начнут его разрабатывать. И полная спецификация часто требует столько же работы, сколько и сама разработка программного обеспечения, а иногда даже больше. Это означает, что процесс создания программного обеспечения является одновременным и процессом его спецификации. То есть описание его функциональности, взаимодействий, необходимых входящих данных, алгоритм их обработки и того, что будет на выходе. В процессе разработки раскрываются новые детали и требования, что приводит к постоянным изменениям и адаптациям. С одной стороны, это создаёт большие возможности для развития продукта. С другой стороны, подразумевает недоразумение и ошибки коммуникации относительно того, что именно должно быть создано. Хотя попытки решить эту проблему с помощью более детальных спецификаций или моделей, ну аналогичных чертежам в строительстве, регулярно предпринимаются, они оказались менее эффективными для программного обеспечения из-за его гибкой природы. Соответственно, нам с вами нужно использовать гибкие методы. для того, чтобы фиксировать объемы, для того, чтобы получать те результаты, которые с одной стороны являются необходимыми и достаточными, с другой стороны позволяют достичь необходимых целей. Но по мере роста функционала, роста требований, растет и функционал, и это работает по методу снежного кома. Следующий эффект – это эффект наблюдателя. Как он проявляется? В разработке ПО это означает, что сам акт использования или наблюдения за работой программного обеспечения меняет ваше представление о том, каким оно должно быть. Когда пользователи начинают работать с программой, они часто обнаруживают новые возможности использования или недостатки, которые не были предусмотрены во время начального проектирования. И этот эффект усиливается, если разработчики и конечные пользователи не взаимодействуют друг с другом. Организации, которые не слышат обратную связь, не получают обратную связь от пользователей, часто сталкиваются с серьезными последствиями эффекта наблюдателя, что обычно приводит к созданию некачественного программного обеспечения. Согласитесь, что требования к программному обеспечению от разработчика и от конечного пользователя очень часто отличаются. И вот разная картина мира, разное понимание ожидаемого результата, с одной стороны, естественно, исходя из разных ролей, с другой стороны, разорванность коммуникации приводит к тому, что этот эффект накапливается и в итоге может привести к тому, что данный софт будет не востребован. Поэтому этот эффект также надо учитывать и закладывать некие шаги для того, чтобы его минимизировать. Теперь вопрос. Данные факторы не существуют не в вакууме, они взаимно влияют друг на друга. Ну, например, эффект наблюдателя часто приводит к проблеме циркулярной спецификации, поскольку новые наблюдения требуют пересмотра начальных планов. В свою очередь, предельное состояние программного обеспечения позволяет легко вносить изменения на основе новых наблюдений, может как улучшить продукт, так и привести к его чрезмерной сложности. Давайте разберемся, как понимать эти вопросы на практике. Значит, если мы понимаем эти факторы, мы можем улучшить процесс разработки и коммуникацию между заинтересованными сторонами. В частности, Осознание предельного состояния поможет различать более чётко жёсткие и мягкие ограничения. Соответственно, мы можем быть более гибкими и внедрять новые подходы без каких-то ограничений, которые были сформированы прошлым опытом. Признание проблемы циркулярной спецификации эффекта наблюдателя подчеркивает необходимость итеративного подхода к разработке. И это помогает планировать с учетом неизбежных трений в процессе разработки между разработчиками, пользователями, ну и, собственно говоря, теми, кто контролирует разработчиков и теми, кто помогает пользователям максимально эффективно использовать подобное решение. Понимание эффекта наблюдателя подчеркивает важность тесного сотрудничества между разработчиками и пользователями на протяжении всего процесса разработки. Таким образом, понимание триады факторов, которые объясняют природу программного обеспечения, является ключевым для эффективной разработки программного обеспечения. Эти факторы объясняют, что часто делает создание программного обеспечения сложным и непредсказуемым процессом. С другой стороны, если мы с вами учитываем данные факторы и опираемся на них при планировании проектов, то мы можем создавать более эффективные процессы разработки, и быстрее давать ценности конечным потребителям, усиливать доверительные отношения между потребителями и разработчиками и, соответственно, работать в длинную, создавать полезные продукты и масштабировать наш бизнес. Принимайте значения, возможности и потенциальные риски, которые несут данные факторы при разработке программного обеспечения. Это первое. Используйте сильные стороны и минимизируйте проблемы, о которых мы говорили сегодня. Это позволит вам дольше работать с клиентами, помогать им создавать более качественные продукты, ну и, соответственно, масштабировать бизнес. Желаю всем новых крупных контрактов. До скорой встречи.