Сколько стоит разработка: 5 мифов о затратах на IT-продукт

«IT-разработка – это слишком дорого», «Невозможно оценить эффективность IT-системы» – это лишь некоторые утверждения, которые говорят о недоверии бизнеса к технологиям. Однако изменения на рынке подтолкнули компании к усилению цифровизации. Мы более 20 лет разрабатываем ПО и сейчас получаем много запросов как на адаптацию готовых IT-систем, так и на разработку собственных уникальных продуктов. Исследуем пять популярных мифов о финансовой стороне IT-разработки и поделимся наблюдениями со всеми, кто планирует создание IT-продукта.

Миф 1. IT-разработка – это всегда сложно, дорого и долго

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

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

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

Другими словами, можно запустить систему, используя 20-30% от общего бюджета. Продажи начнут «отбивать» часть потраченных средств и финансировать следующие этапы разработки. Например, в нашем портфолио есть медицинский проект для сети клиник Великобритании, который мы развиваем более 10 лет. При этом его первый релиз вышел через 8 месяцев после старта. Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней. К слову, этот продукт мы продолжаем дорабатывать и дополнять новыми современными фичами.

Миф 2. Можно сэкономить, передав задачи разработки No-Сode-системам

No-Code – это способ реализации IT-продуктов при помощи специальных платформ, без написания кода вручную. Его можно использовать для создания сайта компании, корпоративного портала, интернет-магазина, игрового приложения и других IT-решений. Таким путем родилось немало сервисов и приложений, в основном, зарубежных – Tavalo, Reachr, Look App, Comet и другие.

Чтобы передать задачи разработки No-Code-платформам, нужно серьезное основание. Например, доказанная гипотеза о том, какие бизнес-выгоды принесет такой шаг. На наш взгляд, вместо того, чтобы сокращать ресурсы, стоит задуматься, на что их выделить. Исследуйте возможности No-Code-платформ для решения конкретных бизнес-задач. При этом важно понять, что и насколько изменится в бизнесе, а главное – когда это произойдет.

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. Потом покажите результат своим клиентам или инвесторам, протестируйте вместе с ними, получите обратную связь. Если все устраивает, можно думать, как это развивать.

Вывод: No-Code-платформы удивляют возможностями и манят простотой освоения. Их действительно стоит изучать, но только вместе с имеющимися инструментами – использовать как возможность диверсифицироваться, усилить команду, расширить кругозор и компетенции разработчиков. Не стоит рубить сплеча и кардинально менять систему работы, если есть слаженная IT-команда.

У No-Code есть свои особенности и ограничения. Например, такие платформы не подойдут для создания высокотехнологичных решений, финтех-продуктов, а также для больших проектов при последующем масштабировании сервиса до нескольких десятков тысяч пользователей. Кроме того, выбрав конкретный No-Code-инструмент, потом вы не сможете скачать себе код проекта и останетесь работать на выбранной площадке, оплачивая обслуживание и стоимость лицензии.

Миф 3. Можно «собрать» IT-систему из доступных продуктов

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

Безусловно, правильно подобранное сочетание может помочь на старте проекта, но опасно полагать, что такие решения всегда будут «двигаться в одном направлении» с вашей компанией и одинаково быстро справляться с потребностями бизнеса, подстраиваясь под текущие реалии.

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

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

Вывод: как показывает наша практика, чем сложнее планируемый продукт и чем «взрослее» существующий, тем очевиднее нужна индивидуальная разработка или модернизация с архитектурным решением, которое будет:

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Миф 4. Не нужно переплачивать, соберите команду из джунов

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

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

Безусловно, на проекте всегда есть задачи разного уровня сложности. Заставлять мидла или сеньора заниматься простыми задачами – экономически невыгодно, поэтому определенный состав джунов на проекте должен быть, но, разумеется, не вся команда. В практике IT-компаний есть такой жизненный цикл взаимодействия: джун обучается, получает практический опыт, мидлы и сеньоры выполняют приоритетные задачи и по мере обучения подключают к ним джунов. Все обмениваются опытом и знаниями в процессе создания продукта, разработчики растут: джун до мидла, мидл до сеньора, сеньор до архитектора. В результате: заказчик получает продукт, компания-аутсорсер – рост квалификации своих сотрудников и довольного заказчика. Win-Win: все довольны.

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

  • Требования заказчика: насколько качественно они проработаны, детализированы и сформулированы в окончательной редакции – не планирует ли заказчик их менять.
  • Сложности проекта, его размер и объем задач, помимо кодинга: аналитика, дизайн, различные виды тестирования, CI/CD...
  • Технологический стек.
  • Наличие у специалистов опыта реализации подобных проектов.

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

Миф 5. Нет смысла тратиться на аналитику проекта

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

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

Какие задачи помогает решать Discovery-фаза

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

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

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

3. Стартап-изобретатель – человек из цифровой сферы, который увидел возможность уберизации сложившейся бизнес-модели. В этом случае подрядчик вместе с заказчиком погружается в предметную область, в некоторых случаях – с привлечением научной экспертизы. Далее проводит Customer Development, составляет перечень нужных пользователю функциональностей, определяет приоритеты и описывает наиболее удобные сценарии для пользователей. В итоге, быстро выпускает минимальный жизнеспособный продукт (MVP) для проверки возможности уберизации бизнес-модели в боевых условиях.

4. Крупное предприятие понимает, что можно что-то улучшить в своей деятельности – оптимизировать затраты или увеличить прибыль. Для этого с помощью IT нужно оптимизировать и автоматизировать существующие процессы. Здесь сначала проводится интервью со всеми заинтересованными сторонами, исследуется комплекс имеющихся на предприятии IT-систем и их взаимодействий, описываются существующие бизнес-процессы. В итоге становится понятно, какие процессы можно оптимизировать. Далее исследуются большие данные клиента – выявляются паттерны – для этого рекомендуем информативные дашборды. В итоге получаем концепцию комплексного решения и предварительную информацию о бюджете и сроках реализации проекта.

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

Безусловно, это не все мифы, которыми полон мир IT. Пишите в комментариях, с какими утверждениями сталкивались вы, а мы постараемся дать им экспертную оценку с точки зрения практики.

Читайте также:

Расскажите коллегам:
Комментарии
CIO, Магнитогорск
Евгений Равич пишет:
Не смог понять отсылку к front end / back end. Есть несколько рабочих подходов к  сокращению бюджета проекта, которые могут помочь заказчмку оценить сложность и риски. Можно поговорить об этом.

Евгений, я пытался пояснить, что когда клиент (ещё не заказчик) выдвигает требования - он мыслит как правило визуальным представлением (экран, форма, картинка, кнопочка), при этом на этапе требований уже часто не знает какая логика реализуется, чтобы две цифры оказались рядом абсолютно разного бизненс-уровня. Как пример приведу: Клиент говорит, хочу видеть в online затраты на материалы, которые цех потратил. Штуки мы оперативно получаем, а стоимость на другом уровне инф.модели. Надо принять некое бизнес-правило. Если это производственное предприятие и длинная производственно-технологическая цепь, то и данные надо "уметь" преобразовать. Всё это и решается не на фронте, а на бэке (уровень СУБД).

И на этапе - "Сколько стоит" - это может от рубля и до бесконечности.

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

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

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

А потом ...опс.... черный лебедь приземлися. 

И тут без посредника (РП -который называется, ну ни как....). Главное, чтобы умел коммуникации настроить и риски проработать.

Генеральный директор, Москва
Юрий Волщуков пишет:
Евгений Равич пишет:
Не смог понять отсылку к front end / back end. Есть несколько рабочих подходов к  сокращению бюджета проекта, которые могут помочь заказчмку оценить сложность и риски. Можно поговорить об этом.

Евгений, я пытался пояснить, что когда клиент (ещё не заказчик) выдвигает требования - он мыслит как правило визуальным представлением (экран, форма, картинка, кнопочка), при этом на этапе требований уже часто не знает какая логика реализуется, чтобы две цифры оказались рядом абсолютно разного бизненс-уровня. Как пример приведу: Клиент говорит, хочу видеть в online затраты на материалы, которые цех потратил. Штуки мы оперативно получаем, а стоимость на другом уровне инф.модели. Надо принять некое бизнес-правило. Если это производственное предприятие и длинная производственно-технологическая цепь, то и данные надо "уметь" преобразовать. Всё это и решается не на фронте, а на бэке (уровень СУБД).

И на этапе - "Сколько стоит" - это может от рубля и до бесконечности.

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

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

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

А потом ...опс.... черный лебедь приземлися. 

И тут без посредника (РП -который называется, ну ни как....). Главное, чтобы умел коммуникации настроить и риски проработать.

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

Мне проще идти от результата. Если есть понимание требований заказчика, то практически всё остальное - опыт и искусство менеджера проекта. Компьютеры так или иначе применяются примерно 70 лет, нет смысла предполагать, что мы говорим о неизвестном и должны двигаться без карты нехожеными тропами.

Но именно опытный менеджер проекта должен собрать всё воедино (а исходных данных может быть осень много) и довести проект до желаемого результата. Есть у него шансы - есть. Гарантирован успех - конечно, нет, проектов без рисков не бывает. Знаем ли мы, как сделать лучше, быстрее или дешевле - обычно такие варианты можно найти и обсудить.  Согласны?

CIO, Магнитогорск
Евгений Равич пишет:
Знаем ли мы, как сделать лучше, быстрее или дешевле - обычно такие варианты можно найти и обсудить.  Согласны?

Евгений, однозначно.

Главное - чтобы обе стороны (Заказчик и Исполнитель) смотрели в одну сторону.

Директор по развитию, Москва
Миф 1. IT-разработка – это всегда сложно, дорого и долго

Это не миф. Это факт, по крайней мере в части "дорого" с учетом текущей стоимости человекочаса разработчика.

Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней.

MVP это всегда вершина айсберга. Да, он как-то позволяет проверить гипотезу, но не дает абсолютно никакой информации о "стоимости-сроках" разработки конечного продукта.

Кстати, 100 дней, это сколько в фактических человеко днях? Одно дело, когда половина стажера работает 100 дней, другое дело, когда команда из 20 разработчиков по рейту 5000 руб/час. Тогда и увидим как это всё "недорого".

IT-менеджер, Красноярск

Безусловно, это не все мифы, которыми полон мир IT. 

Конечно. Еще можно взять отрицание от ваших 5-и утверждений и написать еще одну подобную статью. 

Александр Ковалёв +2923 Александр Ковалёв Инженер, Омск

Теперь настала моя очередь. Для начала цитата:

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

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

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

Сюда же цитата:

Другими словами, можно запустить систему, используя 20-30% от общего бюджета. Продажи начнут «отбивать» часть потраченных средств и финансировать следующие этапы разработки.

Как показывает практика, только 5% проектов выходят из "раннего доступа".

При этом его первый релиз вышел через 8 месяцев после старта. 

На заметку автору: Стандартный срок разработки проекта средней сложности занимает от 3 до 6 месяцев. Прикладной программы - не более 3 месяцев. 

Цитата выше - наглядный пример, какая минимальная цена отстуствия тестирования "в соседней комнате". 

Александр Ковалёв +2923 Александр Ковалёв Инженер, Омск

Далее о No-Code в целом, но сначала цитата: 

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

Идиотское название, если честно, для прикладного софта, который позволяет автоматически сделать те вещи. которые обычно программисты делают в XML, таблицах CSS или набором параметров объектов. 

Делать полигональные модели в 3Ds Max тоже не больно сложная задача, я бы даже назвал её медитативной. 

Рисовать в Photoshop или другом инструменте визуальные компоненты и макеты дизайнеру - тоже не супер сложная задача. 

Более того, даже "рисовать" визуальное окно прикладного приложения тоже не требует написания большого кода. 

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

Чтобы передать задачи разработки No-Code-платформам, нужно серьезное основание. Например, доказанная гипотеза о том, какие бизнес-выгоды принесет такой шаг. На наш взгляд, вместо того, чтобы сокращать ресурсы, стоит задуматься, на что их выделить. Исследуйте возможности No-Code-платформ для решения конкретных бизнес-задач. При этом важно понять, что и насколько изменится в бизнесе, а главное – когда это произойдет.

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

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

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

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. 

На заметку автору: MVP и прототип - это одно и тоже. 

У No-Code есть свои особенности и ограничения. Например, такие платформы не подойдут для создания высокотехнологичных решений, финтех-продуктов, а также для больших проектов при последующем масштабировании сервиса до нескольких десятков тысяч пользователей.

А знаете где ограниченний нет? У Лобстера. Я хоть и читал больше мемуары тех, кто сайты писал в обычном блокноте, но был приятно удивлён тому, что есть адекватная IDE для веба. 

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

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

Александр Ковалёв +2923 Александр Ковалёв Инженер, Омск

Об кастомизируемых CRM:

Вывод: как показывает наша практика, чем сложнее планируемый продукт и чем «взрослее» существующий, тем очевиднее нужна индивидуальная разработка или модернизация с архитектурным решением, которое будет:

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Вообще-то есть вполне себе кастомизируемые СRM, как зарубежные, так и отечественные

Если я не ошибаюсь, то компания Валерия Овсия как раз предоставляет CRM с интеграциями своих модулей на C#. 

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

Партнер, Москва
Александр Ковалёв пишет: Вообще-то есть вполне себе кастомизируемые СRM,

Можно подумать, что вы читали статью? :) Вы процитировали автора, но похоже сами не прочитали выделенное своей цитатой из статьи, о решении которое может ...

Адаптироваться к новым требованиям

Это уже был ответ на ваш текст. А что касается No-Code, то он успешно использовался и раньше при разработке прототипов десктопных приложений. А в инете будет преобладать уже года через 2-3, и займет, скорее всего, 70-80% рынка разработки готовых приложений.

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

Партнер, Москва

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

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

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

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