LeadStartup
Виктория Щепина
Виктория Щепина
Продакт–менеджер

Изучите пять основных принципов, которые каждый руководитель проектов по разработке ПО должен знать для обеспечения успеха и эффективности процессов.

Управление разработкой — необходимо для эффективного управления процессом разработки программного обеспечения
Product Development Processes by Developer for Products
Насмотренность: разработка, TDD, CI/CD, SOLID, etс.

Что такое управление разработкой программного обеспечения?

Разработка программного обеспечения (ПО) – это комплексный последовательный подход к созданию программных продуктов и приложений. Качество и конкурентоспособность продукта во многом зависят от того, насколько эффективным будет выстроен процесс управления разработкой. Если весь жизненный цикл был пройден успешно, то на выходе потребители получают продукт, соответствующий пользовательским требованиям.

Чтобы управление разработкой программного обеспечения приносило ожидаемые результаты, важно применять методики и инструменты, которые соответствуют целям компании. Это подразумевает оптимизацию ресурсов и бюджета, а также повышение уровня квалификации членов команды. Таким образом, получится в короткие сроки получить качественный программный продукт.

Теперь рассмотрим сам процесс создания ПО, чтобы обозначить важность каждого этапа, который необходимо пройти на пути достижения цели.

Жизненный цикл разработки программного обеспечения.

Разумеется, существует не один метод построения жизненного цикла разработки программного обеспечения. Этапы и их последовательность будут отличаться в зависимости от той модели разработки, которая была выбрана командой для создания программных продуктов.

Среди всех методов организации процесса разработки одним из самых популярных является Software Development Life Cycle (SDLC). Данная концепция позволяет осуществлять комплексное управление всеми этапами создания программного продукта. Благодаря этому разработчики могут обеспечить достойное качество ПО, а также его надежность и соответствие запросам конечных пользователей.

SDLC выделяет основные этапы жизненного цикла разработки. Ниже рассмотрим каждый из них.

Планирование.

Даже на этапе планирования нельзя быть полностью уверенным, что проект состоится и принесет ожидаемые результаты. Но именно здесь закладываются основы будущего программного продукта.

Данный этап подразумевает составление плана работ, который в дальнейшем может корректироваться в зависимости от определенных требований к продукту. Также определяются ресурсы, необходимые для создания ПО. Кроме того, формируется команда, внутри которой распределяются обязанности по различным задачам. Обозначаются сроки выполнения работы и составляется график, по которому будут следовать все участники проекта.

Анализ требований.

На этом этапе специалисты из команды разработки занимаются сбором и анализом данных по продукту. То есть, рассматриваются как внутренние аспекты, так и внешние требования заказчика, его возможности, текущее состояние бизнеса, положение дел на рынке и т.д. Это позволит создать продукт, который будет соответствовать всем запросам бизнеса и конечных пользователей, а также будет конкурентоспособным.

В завершении этого этапа команда имеет подробный документ со всеми требованиями к программному продукту, которых необходимо достичь в установленные сроки.

Проектирование и дизайн.

Чтобы буквально представить то, каким будет продукт, необходимо создать его прототип. Для этого разрабатывается его архитектура. На ее основе разработчики будут понимать, какие компоненты будет содержать система, какие алгоритмы должны выполняться разными функциями, каким будет пользовательский интерфейс и т.д.

Это также подразумевает создание дизайн–макета пользовательского интерфейса и составления технической спецификации.

Разработка.

Самый длительный и ответственный этап, на котором происходит написание кода. Его создают уже с учетом не только требований, описанных в документации, но и внешнего вида, который был определен на предыдущем этапе жизненного цикла.

Здесь создаются различные компоненты системы, а также выстраивается взаимосвязь между ними, чтобы продукт действительно мог работать.

Тестирование и интеграция.

Это обязательный этап, без которого невозможно выпустить ПО на рынок или передать его в эксплуатацию заказчику. Проверяются как отдельные компоненты системы, так и их взаимосвязь. Вообще тестирований несколько, и они изучают различные аспекты программы. В конце осуществляется полная проверка, которая должна подтвердить работоспособность ПО и его соответствие всем требованиям.

Обнаруженные недостатки, узкие места, баги и прочее, отправляется на доработку команде разработки. Это происходит до тех пор, пока ошибки не перестают быть критичными и не могут серьезно влиять на эффективность программного продукта или приложения.

Поддержка.

Это этап сопровождения продукта. Он включает в себя доработку ПО, исправление оставшихся багов, обновление с целью улучшения и т.д. Также команда предоставляет техническую поддержку юзерам и реагирует на их обращения. Все это позволяет улучшить продукт и пользовательский опыт.

Каждый из перечисленных этапов очень важен. В целом они повторяются в различных моделях и методологиях разработки с учетом собственных нюансов. То есть где–то они выполняются строго последовательно, а где–то могут происходить параллельно, чтобы сократить жизненный цикл разработки.

Модели управления разработкой программного обеспечения: Последовательная.

Разработка программного обеспечения происходит по определенным принципам. Они заложены в различных моделях, которые позволяют контролировать процесс создания продукта. Каждая из этих моделей имеет множество конкретных методологий со своими отличительными чертами, но о них мы поговорим позже.

Сейчас рассмотрим именно модели, которые объединяют под собой различные схожие подходы к разработке по общим признакам.

Последовательная модель.

Еще ее называют водопадной или каскадной, так как она подразумевает последовательное выполнение всех этапов разработки, сродни потокам водопада. То есть ни один из шагов не может начаться раньше предыдущего, потому что это ломает логику процесса создания продукта.

Это самая старая модель разработки программных продуктов, которая возникла ещё в 1970-х годах, и она не перестает быть актуальной для некоторых видов проектов. Рассмотрим её плюсы и минусы.

Преимущества.

  • Четкость и предсказуемость действий.

Все требования к проекту определяются и согласовываются на начальных этапах и не могут изменяться в процессе разработки. Поэтому необходимо четко и подробно составить документацию, чтобы она не вызывала разночтений или каких–либо уточняющих вопросов во время создания продукта. Не должно возникнуть ситуации, в которой кто–то из участников проекта выполнит действие, не соответствующее техническому заданию.

  • Нет сложностей с пониманием того, что и как делать.

Каждый член команды обязан соблюдать техническое задание проекта и прочую сопутствующую документацию. То есть абсолютно каждый участник должен понимать свои задачи и каким должен быть конечный итог. Причем результаты должны быть предсказуемыми и относительно его действий, и относительно общего результата деятельности команды.

  • Подходит крупным проектам с высоким уровнем контроля бюджета.

Заказчик четко обозначает стоимость проекта ещё до начала работ, и это не просто так. Это значит, что здесь исключены внесения изменений, которые увеличат бюджет. Есть четкое понимание того, каким должен быть конечный продукт и то, какое количество средств на это понадобится. В гибких методах разработки такое невозможно.

Отлично подходит для типовых проектов, которые уже не раз выполнялись командой, и они не требуют гибкости. Здесь нет потребности в изучении и внедрении новых технологий, а все методологии и инструменты для разработки уже известны заранее.

  • Не требуется постоянное участие заказчика в каждом этапе разработки.

В случае, если заказчик не имеет достаточного количества времени на то, чтобы следить за промежуточными результатами и давать по ним обратную связь, то водопадная модель подходит больше всего. Он принимает участие лишь в самом начале работы над проектом и принимает готовый продукт. Часто так бывает в сферах, где требуется программа, соответствующая четким регламентам и документации.

Недостатки.

  • Отсутствие гибкости в случае возникновения новых условий и требований.

В экстренных ситуациях, когда возникает потребность внести изменения в продукт в разгар разработки, сделать это не получится. То есть придется ждать завершения полного цикла и только потом вносить изменения. Это добавляет работы разработчикам, а также увеличивает бюджет. Поэтому на этапе планирования нужно быть максимально уверенным в требованиях к продукту. Для этого необходимо провести анализ текущих внутренних и внешних факторов, которые могут повлиять на конечный вид продукта и выстроить прогноз на будущее.

  • Высокий уровень рисков, которые возникают из–за переработок.

Если заказчик все–таки готов увеличить бюджет и внести изменения в продукт в процессе разработки, то возрастает уровень рисков. Они связаны со срывами сроков выполнения проекта, ошибками в коде, переработками и т.д. Все это может снизить качество конечного продукта и увеличить количество багов, что сделает хуже пользовательский опыт.

  • Исполнитель жестко ограничивает бюджет и постоянно его контролирует.

Исполнитель имеет высокий уровень ответственности за проект, которую невозможно в полной мере разделить с заказчиком. Именно команда разработки должна лучше знать, какой бюджет понадобится для разработки продукта, поэтому если они просчитаются, то вина будет исключительно их. Тогда участникам проекта, по сути, придется из кожи вон вылезать за свой собственный счет, чтобы не подвести заказчика.

  • Нельзя применять в проектах, в которых часто меняются требования.

Если бизнес заведомо находится в переменчивых условиях, которые нельзя не учитывать при создании программного продукта или приложения, то водопадная система здесь не подходит. Она не позволит оперативно вносить изменения и не повышать при этом уровень рисков.

  • Заказчик мало участвует в разработке, поэтому возникают сложности с согласованием.

В случае, если в самом начале заказчик не был до конца уверен в том, каким должен быть конечный продукт, то в конце он может оказаться недоволен результатом. Не факт, что после этого он продолжит сотрудничество именно с этими разработчиками.

Модели управления разработкой программного обеспечения: Итеративная.

Более современной моделью разработки программного обеспечения является итеративная модель. Она учитывает недостатки каскадной модели, поэтому в процессе работы над проектом допустима гибкость. Это возможно за счет того, что весь жизненный цикл разбит на короткие итерации.

В рамках каждой из них ведется разработка над отдельными модулями системы, то есть команда выполняет определенный набор задач, которые включают в себя все этапы от анализа требований до тестирования. Таким образом, процесс создания программного продукта оптимизируется, а значит и сокращается жизненный цикл продукта.

Ниже рассмотрим основные плюсы и минусы итеративного подхода к разработке ПО.

Преимущества.

  • Данная модель снижает возникновение рисков за счет того, что большинство ошибок и проблем удается обнаружить на ранних этапах, то есть ещё до того, как они станут критическими. Команда фокусируется только на актуальных задачах и не отвлекается на посторонние, которые сейчас не нуждаются во внимании. Это позволяет углубиться в процесс и не пропустить важных деталей.

  • Итерации дают возможность сделать процесс разработки гибким и внедрять необходимые изменения, которые возникают при создании продукта на разных этапах жизненного цикла. Добавить новую функцию или исправить выявленную ошибку возможно в рамках следующей итерации, а не после завершения всех этапов разработки.

  • Регулярная обратная связь от заказчика в течение всего цикла разработки программного продукта. Кроме того, на последних этапах тестирования возможно подключить конечных пользователей, что позволит улучшить продукт и максимально точно приблизить его к требованиям юзеров.

  • Возможен выпуск продукта на рынок с его минимальной ценностью (MVP), что делает его более конкурентным в определенных условиях. Поднять его ценность возможно за счет обновлений ПО, что даже выгоднее, потому что эти изменения вносятся с учетом полевых исследований. То есть продукт получается максимально близким к требованиям, которые были обозначены на этапе планирования.

Недостатки.

  • Риск того, что архитектура может посыпаться. В начале она формируется на основе первоначальных требований к продукту, но если возникает необходимость внести изменения, то они могут вызвать противоречия в системе. Это может отразиться на производительности и привести к появлению множества багов и узких мест.

  • Возможно увеличение сроков разработки и бюджета. Для разработчиков это скорее преимущество, потому что они обеспечены работой. Но заказчик всегда рассчитывает получить максимум выгоды за минимальные траты. В целом неопределенность со сроками может выматывать и саму команду разработки, так как зачастую они одновременно занимаются не одним проектом.

Вообще, сложно найти такие продукты, для которых не подойдет данная модель разработки. Она позволяет улучшать качество ПО на каждом этапе жизненного цикла, что подходит абсолютно каждому заказчику, независимо от его сферы деятельности.

Модели управления разработкой программного обеспечения: Гибкая.

Это следующая модель разработки, которая следует после итерационной. По сути, это совокупность гибких методологий Agile, например, таких как Kanban и SCRUM. Это разные подходы, но они имеют общие признаки. Это и объединяет их в гибкую модель разработки.

В ее основе также находятся итерации, которые ещё больше вовлекают заказчика и его заинтересованных лиц в процесс разработки программного продукта. То есть ему доступны все промежуточные результаты проекта. Разумеется, он имеет возможность на них повлиять.

Такой подход больше всего подходит компаниям с такой же гибкой системой управления персоналом, когда ответственность между членами команды распределяется горизонтально. А ещё в тех случаях, когда разработчики постоянно генерируют новые творческие и инновационные идеи.

Теперь рассмотрим плюсы и минусы гибкой модели разработки программного обеспечения.

Преимущества.

  • В рамках итерации решаются только актуальные задачи, которые помогут реализовать модуль качественно. И даже если вдруг по результатам тестирования обнаружены какие–то ошибки, то они будут исправляться уже в следующей итерации. Таким образом, удается контролировать прогресс выполнения проекта и равномерно распределять нагрузку на специалистов. Что в свою очередь снижает риск влияния человеческого фактора, возникшего из–за усталости.

  • Продукт постоянно улучшается, из–за чего растет его качество, соответствие требованиям и в конечном итоге конкурентоспособность на рынке. Юзеры получают позитивный пользовательский опыт, который по большей части их удовлетворяет. Все это возможно благодаря получению постоянной обратной связи. Предложить улучшения могут члены команды разработки, заказчик и его заинтересованные лица, а также сами пользователи.

  • Несмотря на то, что на начальном этапе формируется определенное техническое задание и требования к продукту, допустимы отступления, если они позволят сделать ПО лучше. Главное обосновать эти подвижки и доказать их эффективность.

Недостатки.

  • Важно перед тем, как внедрить очередное улучшение, удостовериться, что от него действительно будет польза. В первую очередь, совершенствовать ключевые функции, которые оказывают огромное влияние на производительность и эффективность продукта. Иначе есть риск не сократить жизненный цикл разработки, а наоборот сильно его увеличить. Не особенно важные улучшения можно оставить для обновлений продукта в будущем.

  • При организации работы над особенно сложным и крупным проектом может потребоваться привлечение нескольких команд разработки. Это не только увеличит расходы, но и может привести к трудностям с выстраиванием коммуникаций между подразделениями.

В реальной жизни модели и методы разработки могут чередоваться и комбинироваться между собой. Вряд ли действительно можно встретить команду, которая придерживается только одного варианта, полностью соблюдая все его принципы.

Product Development Processes by Developer for Products

Вам предстоит общаться с разработчиками и для этого необходимо знать их язык хотя бы поверхностно

Погружение продакта в технологические аспекты разработки

Как подружить продакта и команду разработки?

Как работают языки программирования?

В этом видео Андрей рассказывает о различиях языков программирования с точки зрения влияния на бизнес.

Python vs Java

Еще немного материала про различия языков программирования в контексте бизнеса на примере Python и Java.

Что происходит когда мы вбиваем URL в адресную строку

Что происходит когда мы вбиваем URL в адресную строку? Это полезно знать даже обычным интернет–юзерам.

Про типы сетевых протоколов

Какими бывают сетевые протоколы? И почему HTTPS важен для вашего продукта?

Про GIT и базы данных

Где и как хранятся данные и код продукта? Разбираемся.

Про Deployment Process

Как изменения в коде продукта уходят в релиз? И как выглядит Deployment процесс?

Про API

Что такое Application Programming Interface? И как продукты обмениваются данными между собой?

Микросервисная архитектура

Почему многие продукты переходят на микросервисную архитектуру? Это вообще зачем?

Архитектура огромных сервисов

Как устроены архитектуры таких гигантов как Netflix и TikTok? Смотрим.

Компоненты системного дизайна

Базовые правила системного дизайна.

Ответы на вопросы выпускника по разработке

В этом видео Андрей отвечает на вопросы нашего выпускника Владимира, который кстати успешно вышел на роль CTO после прохождения нашей программы.

Инженерная терминология для менеджеров

  1. Architecture: Общая структура и дизайн системы, включая ее компоненты и их взаимоотношения.

  2. DevOps: Набор практик, объединяющих разработку программного обеспечения (Dev) и IT–операции (Ops), направленных на улучшение и стабилизацию процессов разработки и обеспечение непрерывной доставки.

  3. Continuous Integration (CI): Практика частого внедрения изменений кода в общий репозиторий, за которой следует автоматическое тестирование.

  4. Continuous Deployment (CD): Практика автоматического внедрения каждой готовой сборки пользователям без участия человека.

  5. Version Control: Система, которая записывает логи изменения файлов или наборов файлов со временем, чтобы в дальнейшем можно было быстро восстановить конкретные их версии.

  6. Repository (Repo): Централизованное место, где разработчики хранят код и отслеживают изменения, например используя системы управления версиями, такие как Git.

  7. Merge: Процесс интеграции кода из одной ветви репозитория в другую.

  8. Pull Request (PR): Метод, используемый разработчиками для доставки их изменений кода в общий репозиторий. Другие члены команды получают возможность проверки, одобрения или предложения собственных модификаций.

  9. API: Набор протоколов и инструментов, позволяющих различным программным сущностям взаимодействовать друг с другом. Например двум сайтам: Ozon и СДЭК.

  10. SDK: Набор программных инструментов и программ, предоставляемых производителями оборудования или программного обеспечения, которые разработчики могут использовать для создания приложений на определенных платформах.

  11. Framework: Заранее определенная среда, в которой разработчики могут создавать приложения для определенных платформ.

  12. Full-stack: Относится к разработке, которая охватывает как интерфейс пользователя (фронтенд), так и сервер и базу данных (бэкенд). Такой суперразработчик. Сейчас тренд спроса на таких специалистов начал падать.

  13. Frontend: Часть приложения, с которой непосредственно взаимодействуют пользователи. Часто создается с использованием языков и технологий, таких как HTML, CSS и JavaScript.

  14. Backend: Серверная сторона приложения, которая обеспечивает обработку данных, хранение и другие операции за кулисами.

  15. Middleware: Программное обеспечение, которое служит мостом между операционной системой или базой данных и приложениями, например в сети.

  16. Cloud Computing: Хранение и доступ к данным и программам через интернет, а не на жестком диске компьютера.

  17. Server: Компьютер или система, предоставляющая ресурсы, данные, услуги или программы другим компьютерам, называемым клиентами. В основном по хранению данных. Например Yandex Cloud.

  18. Database: Структурированный набор данных, хранящихся в компьютере, к которому можно получить доступ различными способами.

  19. Bug: Ошибка или дефект в программном обеспечении, который приводит к неожиданным результатам или вызывает непредсказуемое поведение системы.

  20. Regression: Программный баг, который заставляет функцию перестать работать как предполагалось после определенного события.

  21. Refactoring: Процесс реструктуризации существующего программного кода без изменения его внешнего поведения.

  22. Unit Testing: Тестирование отдельных единиц или компонентов программного обеспечения на работоспособность.

  23. Integration Testing: Тестирование интерфейсов между компонентами или системами для обеспечения их совместной работы.

  24. Deployment: Процесс предоставления программного обеспечения для использования, путем установки его на пользовательские устройства или размещения на серверах.

  25. Scalability: Способность системы обрабатывать увеличивающееся количество процессов и данных, или потенциальная возможность ее роста для масштабирования в перспективе.

  26. Load Balancer: Устройство или служба, которая распределяет входящий сетевой трафик по нескольким серверам, чтобы ни один сервер не был перегружен.

  27. Virtual Machine (VM): Эмулированное окружение компьютера, работающее на физическом компьютере.

  28. Docker: Платформа для разработки, доставки и запуска приложений в контейнерах.

  29. Microservices: Подход к разработке программного обеспечения, при котором приложение состоит из множества независимых и небольших сервисов.

  30. User Experience (UX): Восприятие и реакция пользователя на взаимодействие с продуктом или услугой.

  31. User Interface (UI): Интерфейс приложения или веб–сайта, через который пользователь взаимодействует.

  32. Codebase: Все исходные коды программного обеспечения или приложения, обычно хранящиеся в репозитории.

  33. Quality Assurance (QA): Процесс обеспечения того, чтобы продукт или услуга соответствовали установленным стандартам и требованиям.

  34. Unit Testing: Тестирование отдельных единиц программного кода для обеспечения их корректной работы.

  35. Regression Testing: Тестирование, чтобы удостовериться, что новый код или функции не повредили существующую функциональность.

  36. Deployment Pipeline: Серия автоматизированных тестов и процедур, которые код должен пройти до доставки в производственное окружение.

  37. Kubernetes: Открытая платформа для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями.

  38. Integration Testing: Тестирование взаимодействия между интегрированными компонентами программного обеспечения.

  39. Load Testing: Исследование работы системы под нагрузкой, чтобы определить ее поведение в реальных условиях.

  40. Git: Распределенная система управления версиями, используемая для отслеживания изменений в исходном коде во время разработки программного обеспечения.

  41. Database: Централизованное хранилище данных, доступ к которым можно получить с помощью программного обеспечения.

  42. SQL: Язык запросов, используемый для взаимодействия с реляционными базами данных.

  43. NoSQL: Нереляционная база данных, которая может хранить и извлекать данные без стандартных таблиц SQL.

  44. Cache: Промежуточное хранилище данных, используемое для быстрого доступа к часто запрашиваемой информации.

  45. RESTful API: Архитектурный стиль веб–сервисов, предоставляющий стандартизированный интерфейс для взаимодействия между приложениями.

  46. Endpoint: Точка конечного взаимодействия в коммуникациях или веб–сервисах.

  47. Serverless Architecture: Подход к созданию и запуску приложений, при котором разработчики не управляют инфраструктурой сервера.

  48. Bug Tracking: Процесс идентификации, записи и корректировки ошибок и других проблем в программном обеспечении.

  49. Technical Debt: Концепция, описывающая "стоимость" будущей работы, вызванную выбором более простого решения перед более сложным.

  50. Data Modeling: Процесс создания абстрактной модели структуры данных.

  51. Machine Learning: Тип искусственного интеллекта, который позволяет системам обучаться без явного программирования.

  52. Big Data: Огромные наборы данных, которые трудно обрабатывать традиционными методами.

  53. Webhook: Метод для улучшения или расширения веб–приложения с использованием пользовательских обратных вызовов.

  54. Dependency: Программный компонент или библиотека, необходимая для функционирования другого программного компонента.

  55. Open Source: Программное обеспечение, исходный код которого доступен публично и может быть изменен или использован кем угодно.

  56. Wireframe: Визуальное представление интерфейса страницы или приложения.

  57. Prototype: Рабочая модель программного обеспечения с основной функциональностью, разработанная для демонстрации и тестирования.

  58. Cryptography: Наука о безопасном кодировании и декодировании информации.

  59. Object-Oriented Programming (OOP): Подход к программированию, при котором программы структурируются вокруг объектов, а не функций и логики.

Любимые технологические процессы

Опишите своими словами подробно 2 наиболее запомнившихся вам технологических процесса разработки продукта: как они устроены, на что влияют?

Рекомендации по настройке общего языка между разработкой и продуктом

Дайте 5 подробных рекомендаций по выстраиванию общего языка между инженерами–разработчиками, остальными участниками продуктовой команды и владельцем продукта.

Насмотренность: разработка, TDD, CI/CD, SOLID, etс.

Разбираемся в инженерных нюансах работы продуктовой команды

TDD, CI/CD, SOLID, etс.

Что означают все эти сложные инженерные термины и как устроены процессы разработки продуктов в команде изнутри?

Интервью с разработчиком

Проведите интервью с любым знакомым разработчиком в том же стиле, который вы услышали на нашем видео этого модуля.

Видеозапись и конспект прикрепите в ответе на это задание.

Инженерная терминология для менеджеров

  1. Architecture: Общая структура и дизайн системы, включая ее компоненты и их взаимоотношения.

  2. DevOps: Набор практик, объединяющих разработку программного обеспечения (Dev) и IT–операции (Ops), направленных на улучшение и стабилизацию процессов разработки и обеспечение непрерывной доставки.

  3. Continuous Integration (CI): Практика частого внедрения изменений кода в общий репозиторий, за которой следует автоматическое тестирование.

  4. Continuous Deployment (CD): Практика автоматического внедрения каждой готовой сборки пользователям без участия человека.

  5. Version Control: Система, которая записывает логи изменения файлов или наборов файлов со временем, чтобы в дальнейшем можно было быстро восстановить конкретные их версии.

  6. Repository (Repo): Централизованное место, где разработчики хранят код и отслеживают изменения, например используя системы управления версиями, такие как Git.

  7. Merge: Процесс интеграции кода из одной ветви репозитория в другую.

  8. Pull Request (PR): Метод, используемый разработчиками для доставки их изменений кода в общий репозиторий. Другие члены команды получают возможность проверки, одобрения или предложения собственных модификаций.

  9. API: Набор протоколов и инструментов, позволяющих различным программным сущностям взаимодействовать друг с другом. Например двум сайтам: Ozon и СДЭК.

  10. SDK: Набор программных инструментов и программ, предоставляемых производителями оборудования или программного обеспечения, которые разработчики могут использовать для создания приложений на определенных платформах.

  11. Framework: Заранее определенная среда, в которой разработчики могут создавать приложения для определенных платформ.

  12. Full-stack: Относится к разработке, которая охватывает как интерфейс пользователя (фронтенд), так и сервер и базу данных (бэкенд). Такой суперразработчик. Сейчас тренд спроса на таких специалистов начал падать.

  13. Frontend: Часть приложения, с которой непосредственно взаимодействуют пользователи. Часто создается с использованием языков и технологий, таких как HTML, CSS и JavaScript.

  14. Backend: Серверная сторона приложения, которая обеспечивает обработку данных, хранение и другие операции за кулисами.

  15. Middleware: Программное обеспечение, которое служит мостом между операционной системой или базой данных и приложениями, например в сети.

  16. Cloud Computing: Хранение и доступ к данным и программам через интернет, а не на жестком диске компьютера.

  17. Server: Компьютер или система, предоставляющая ресурсы, данные, услуги или программы другим компьютерам, называемым клиентами. В основном по хранению данных. Например Yandex Cloud.

  18. Database: Структурированный набор данных, хранящихся в компьютере, к которому можно получить доступ различными способами.

  19. Bug: Ошибка или дефект в программном обеспечении, который приводит к неожиданным результатам или вызывает непредсказуемое поведение системы.

  20. Regression: Программный баг, который заставляет функцию перестать работать как предполагалось после определенного события.

  21. Refactoring: Процесс реструктуризации существующего программного кода без изменения его внешнего поведения.

  22. Unit Testing: Тестирование отдельных единиц или компонентов программного обеспечения на работоспособность.

  23. Integration Testing: Тестирование интерфейсов между компонентами или системами для обеспечения их совместной работы.

  24. Deployment: Процесс предоставления программного обеспечения для использования, путем установки его на пользовательские устройства или размещения на серверах.

  25. Scalability: Способность системы обрабатывать увеличивающееся количество процессов и данных, или потенциальная возможность ее роста для масштабирования в перспективе.

  26. Load Balancer: Устройство или служба, которая распределяет входящий сетевой трафик по нескольким серверам, чтобы ни один сервер не был перегружен.

  27. Virtual Machine (VM): Эмулированное окружение компьютера, работающее на физическом компьютере.

  28. Docker: Платформа для разработки, доставки и запуска приложений в контейнерах.

  29. Microservices: Подход к разработке программного обеспечения, при котором приложение состоит из множества независимых и небольших сервисов.

  30. User Experience (UX): Восприятие и реакция пользователя на взаимодействие с продуктом или услугой.

  31. User Interface (UI): Интерфейс приложения или веб–сайта, через который пользователь взаимодействует.

  32. Codebase: Все исходные коды программного обеспечения или приложения, обычно хранящиеся в репозитории.

  33. Quality Assurance (QA): Процесс обеспечения того, чтобы продукт или услуга соответствовали установленным стандартам и требованиям.

  34. Unit Testing: Тестирование отдельных единиц программного кода для обеспечения их корректной работы.

  35. Regression Testing: Тестирование, чтобы удостовериться, что новый код или функции не повредили существующую функциональность.

  36. Deployment Pipeline: Серия автоматизированных тестов и процедур, которые код должен пройти до доставки в производственное окружение.

  37. Kubernetes: Открытая платформа для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями.

  38. Integration Testing: Тестирование взаимодействия между интегрированными компонентами программного обеспечения.

  39. Load Testing: Исследование работы системы под нагрузкой, чтобы определить ее поведение в реальных условиях.

  40. Git: Распределенная система управления версиями, используемая для отслеживания изменений в исходном коде во время разработки программного обеспечения.

  41. Database: Централизованное хранилище данных, доступ к которым можно получить с помощью программного обеспечения.

  42. SQL: Язык запросов, используемый для взаимодействия с реляционными базами данных.

  43. NoSQL: Нереляционная база данных, которая может хранить и извлекать данные без стандартных таблиц SQL.

  44. Cache: Промежуточное хранилище данных, используемое для быстрого доступа к часто запрашиваемой информации.

  45. RESTful API: Архитектурный стиль веб–сервисов, предоставляющий стандартизированный интерфейс для взаимодействия между приложениями.

  46. Endpoint: Точка конечного взаимодействия в коммуникациях или веб–сервисах.

  47. Serverless Architecture: Подход к созданию и запуску приложений, при котором разработчики не управляют инфраструктурой сервера.

  48. Bug Tracking: Процесс идентификации, записи и корректировки ошибок и других проблем в программном обеспечении.

  49. Technical Debt: Концепция, описывающая "стоимость" будущей работы, вызванную выбором более простого решения перед более сложным.

  50. Data Modeling: Процесс создания абстрактной модели структуры данных.

  51. Machine Learning: Тип искусственного интеллекта, который позволяет системам обучаться без явного программирования.

  52. Big Data: Огромные наборы данных, которые трудно обрабатывать традиционными методами.

  53. Webhook: Метод для улучшения или расширения веб–приложения с использованием пользовательских обратных вызовов.

  54. Dependency: Программный компонент или библиотека, необходимая для функционирования другого программного компонента.

  55. Open Source: Программное обеспечение, исходный код которого доступен публично и может быть изменен или использован кем угодно.

  56. Wireframe: Визуальное представление интерфейса страницы или приложения.

  57. Prototype: Рабочая модель программного обеспечения с основной функциональностью, разработанная для демонстрации и тестирования.

  58. Cryptography: Наука о безопасном кодировании и декодировании информации.

  59. Object-Oriented Programming (OOP): Подход к программированию, при котором программы структурируются вокруг объектов, а не функций и логики.

Дополнительные материалы по разработке для менеджеров

Рекомендуем вам посмотреть материалы канала EngineerSpock: https://www.youtube.com/@EngineerSpock

Также будет полезным поизучать материалы Роберта Мартина с его и других каналов: