что такое фитчи проекта
Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Что так ое «баг» в программировании?
Это довольно частый вопрос, потому что слово «баг» не всегда связано с программированием. В программировании «баг» — это ошибка в программе или в приложении, которая приводит к тому, что программа или приложени е не работают как следует. Само слово «баг» происходит от английского слова «bug». По причине воздействия бага на программу мы получаем продукт, при работе которого происходит нежелательный конечный результат.
Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединя ю т следующие свойства:
Что такое « фича » в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.
Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Анализ функционала: как создавать фичи, которые будут полезны продукту, или что такое Feature/Product Fit
Что такое Feature/Product Fit?
Любая команда старается сделать свой продукт лучше. В большинстве компаний это происходит с помощью запуска новых фич в надежде, что они будут полезны. У компаний нет отлаженных процессов, которые помогали бы им понять, будет эта функция полезна конечному потребителю или нет. Этот процесс должен напоминать поиск соответствия продукта рынку (product/market fit). Но есть и различия.
В случае product/market fit есть три основных компонента, которые вам нужны:
Feature/product fit определяет, насколько ваша фича входит в общую концепцию продукта. Тут похожий процесс:
Это может быть слегка непонятно и сбивать с толку. Фича не только должна использоваться систематически и привлекать клиентов сама по себе, но она также должна улучшать UX продукта в целом. Это очень сложно, поэтому многие релизы проваливаются. Что происходит, когда фича работает на собственное возвращение и вовлечение, но не увеличивает эти же метрики всей компании? Это значит, что она каннибализирует на другой части продукта. Иногда это нормально. До тех пор, пока все эти три показателя не снижаются, запуск фичи может быть оправдан.
Самый популярный пример — это запуск стриминга от Netflix, который каннибализировал на рассылке DVD по почте, но в долгосрочной перспективе оказался стратегическим шагом.
В чём заключается работа команды?
Команда, работающая над конкретным функционалом, концентрируются на улучшении UX своей фичи, а не всего продукта в целом. Им хочется, чтобы все использовали эту фичу и сами иногда усложняют работу сервиса, отвлекая от основного продукта.
Если вы отвечаете за какую-то фичу, ваша работа заключается не в том, чтобы как можно больше людей использовали её. Ваша работа в том, чтобы как раз найти своё место в продукте, свой feature/product fit. Это можно сделать, проверяя метрики, о которых мы говорили выше (возвращение и активацию в фичу, а также возвращение, привлечение и монетизацию в основной сервис). В это время вы также должны определить, для кого подходит этот функционал как часть продукта (скорее всего, это не будут новые пользователи). Некоторые функции должны быть направлены на маленький процент пользователей. Тогда функционал становится инструментом, который может быть максимально использован командой для роста своей компании и увеличения общей доли возвращений в продукт, вовлечения и монетизации.
Какие ошибки совершают команды?
Ошибка №1. Рассылать анонс нового функционала по всей емейл-базе
Ваших пользователей интересует только выгода, которую они получают от использования вашего сервиса. Рассылая информацию об обновлениях в одной фиче, вы не доказываете ценность этой функции. Такие письма работают обычно хуже, чем письма об изменениях в основном продукте, зато легко могут повлиять на ценность емейл-канала, а это уменьшит возвращение в основной продукт.
Ошибка №2. Делать баннер на самом видном месте на сайте и рассказывать всем пользователям о вашей новой фиче
Обычно новые фичи нужны очень узкой аудитории и не так нужны всем остальным. Особенно они бесполезны для новых пользователей, которые пытаются освоить самые основы вашего продукта. Такие оповещения отвлекают их от основного функционала и снижают процент активации. Это приблизительно как предлагать участие в марафоне тем, кто только научился ползать.
Ошибка №3. Везде публиковать информацию о новом функционале
Пиар для конкретной фичи — это хорошо, но он не поможет найти feature/product fit. С другой стороны, пиар может пригодиться, когда вы убедитесь, что фича заняла правильное место в продукте и найдёте свою аудиторию. Если это не сделать заранее, пиар вас не спасёт.
Спасибо! Мы уже отправили всё на почту
Многие фичи не пройдут отбор
Многие фичи, над которыми работают продуктовые команды, не нашли своего места в продукте. Когда так происходит, фичи надо удалять. Бывает и так, что старые фичи перестают соответствовать. Если их нельзя актуализировать, их тоже надо удалить. Если вы не измеряли feature/product fit для старых функций, вернитесь и сделайте это. Удаляйте без сожалений, если понимаете, что это не работает. Вот пара примеров того, как Pinterest удаляет части своего функционала:
1. Кнопка like (удалено в 2016).
Люди не понимали разницу между кнопкой Like и Save и это приводило к путаннице.
2. Пины мест (удалено в 2015)
Pinterest пробовал создать особый тип пинов и специальные доски для пинов-мест. Во время экспериментов команда поняла, что это отдаляет их от основной концепции Pinterest.
3. Подпись пользователей/досок в сетке (удалено в 2016).
Указывать пользователей и их доски в самом пине стало бессмысленно после того, как Pinterest сделал пивот от социальной сети к сети по интересам. Это загромождало интерфейс и уменьшало количество выводимых пинов.
Как найти фиче место в продукте или Feature/Product Fit?
Запускайте все фичи в виде теста и смотрите, что выстрелит. Ваша цель — за время этого эксперимента показать новую фичу достаточно большому количеству людей, чтобы можно было сделать выводы. Маленьким компаниям можно тестировать прямо на всей базе клиентов. Для компании вроде Pinterest достаточно будет захватить около 1% аудитории. Обычно для таких экспериментов используют существующую базу, но можно привлекать и платный трафик.
Вот несколько тактик, которые помогли разным компаниям найти свой feature/product fit. Разработка хорошего функционала обычно начинается с анализа данных и исследования пользователей. В этом исследовании важно подгадать правильное время: исследование необходимо проводить так, чтобы у людей была достаточная вовлечённость, и можно было предотвратить предвзятость. Например, при запуске мобильного приложения Grubhub увидели, что оценки пользователей ниже, если они используют геолокацию, чем у тех, кто просто вводил свой адрес. Оказалось, что это проблема в точности определения местоположения, поэтому эту возможность отключили до тех пор, пока не исправили баг.
При анализе Grubhub заметили, что пользователи сомневаются, какой ресторан из поиска выбрать. В браузере можно открыть много вкладок и сравнить, но в приложении так сделать нельзя. Команда выбрала информацию, которая могла бы помочь пользователям принять решение, и начали добавлять ее в результаты поиска. Сейчас в выдаче отображается тип кухни, приблизительное время доставки, минимальный чек, рейтинг в звёздах, количество оценок. На первый взгляд страница стала более загромождённой, но это увеличивает конверсию и удержание.
Так как Grubhub — это агрегатор сервисов по доставке еды, необходимо было оценивать стимулы как стратегию поиска соответствия функционала продукту. Первоначальные данные показали, что у людей, которые начали использовать мобильное приложение, LTV был вдвое выше, чем у тех, кто заказывал через интернет. Поэтому Grubhub предложил скидку 10 долларов на первый заказ через мобильное приложение. Это помогло переключить пользователей из сети в мобильные. Стратегия оказалась очень успешной, и LTV увеличился, несмотря на дополнительное побуждение и скидки.
Также Grubhub использует собственных пользователей, чтобы найти feature/product fit. В то время мобильные приложения только входили в моду, поэтому команда Grubhub мониторил все жалобы в соцсетях и немедленно отвечали.
(не все жалобы такие эмоциональные)
В Pinterest запустили Related Pins (связанные пины) в 2013 и ввели уведомления. Когда вы запинили что-нибудь, вам будут приходить емейлы с предложениями связанных пинов, которые могут вам понравиться. Эти письма были очень успешны.
Pinterest также использует основной функционал продукта. Когда пользователи прокручивали пин, им показывались связанные пины. Но мало людей скроллит дальше самого пина, поэтому их поместили справа от основного, и это увеличило вовлечённость. Поэтому Pinterest начали вставлять связанные пины и в те, которые вы сохранили, что также увеличило вовлечённость.
The Feature/Product Fit чеклист
Отвечайте себе на эти вопросы, когда запускаете новый функционал, чтобы убедиться в успехе.
После подтверждения feature/product fit вы должны спросить себя:
Каждая компания хочет со временем улучшать свой продукт. Вам необходимо начать измерять, как на ваши планы влияют функции, которые вы внедряете. Не забывайте проверять, приносят ли ценности существующие фичи, а если нет, начните их убирать. Задавая себе эти вопросы, вы будете уверены, что вы на пути к созданию фич, которые соответствуют общей концепции вашего продукта и добавляют ценности и вашему бизнесу.
Елена Туровская
Тимлид команды продакт-маркетинга Carrot quest
Что такое фича. Объясняем простыми словами
Фича — дополнительная функция или особенность продукта.
Изначально фичами называли необычные функции в компьютерных программах и играх, потом так стали говорить и про гаджеты, и про технику («Мой чайник светится, когда я его включаю, а у твоего есть такая фича?»).
В языке бизнеса и маркетинга слово «фича» практически приобрело статус термина. Различают несколько видов фич. Например:
Пример употребления на «Секрете»
«Ещё вьетнамцы очень любят смотреть онлайн корейские сериалы. И такая простая фича, как возможность свернуть окно браузера и продолжить смотреть видео в фоновом режиме, им очень понравилась. Те инструменты, к которым мы уже привыкли, здесь ещё просто никем не созданы. Мы там как будто люди из будущего».
(Соосновательница компании СосСос Кристина Мелентьева — о том, как её компания потеснила Google во Вьетнаме.)
Нюансы
Предприниматели, развивая свой бизнес, постоянно находятся в поиске новых фич. Но не всегда просто понять, какая функция окажется полезной, а какая навредит. Для этого существует feature/product fit — процедура оценки потенциальной пользы от новой фичи. Иногда правильное решение — отказаться от лишних функций: например, раньше во «ВКонтакте» у пользователей был рейтинг, а «Инстаграм» позволял организовывать путешествия и объединяться в группы. Оценив пользу этих функций, от них отказались.
Практика
Вы наверняка не раз слышали фразу «Это не баг, это фича». Она описывает ситуацию, когда ошибку пытаются представить как «это так задумано». На самом деле, многие прикольные фишки и функции и правда появлялись случайно, в результате ошибки, а потом становились популярными у пользователей. Например, такое часто случалось в компьютерных играх:
Что дальше? Или как правильно выбрать фичи для разработки
Грамотно и вовремя выбирать фичи для разработки и не прогадать – это про искусство приоритизации. Как найти критерии оценки, необходимые для своего продукта, вырастить стратегические показатели, предложить клиентам еще больше ценности, наладить все внутренние процессы в команде и добиться других наглядных показателей с помощью качественной приоритизации?
Эта статья написана по материалам доклада “Что дальше? Или искусство приоритизации”, с которым я выступил 26 июня на конференции BDS. Marketing.
В докладе я рассказал о том, как мы приоритизируем фичи в компании Hygger.io — системе управления проектами для продуктовых команд.
Прежде чем перейти к описанию нашего процесса, хочу кратко напомнить о том, почему приоритизация так важна.
Почему без приоритизации не выжить?
«Управление продуктом» означает принятие решения о том, что мы делаем для продукта, а затем его реализацию.
Райан Сингер, продуктовая стратегия Basecamp
Управление продуктом состоит из трех больших блоков:
И не будем кривить душой — я думаю, что многие product managers кайфуют от такой «лепки». От возможности влиять на то, каким будет продукт.
Отвлекающие факторы буквально убивают стартапы. Строительство ради строительства подобно самоубийству. Поэтому наличие строгого и честного процесса приоритизации для разработки функций имеет решающее значение для контроля внимания и устранения лишнего.
Бен Йосковитц, автор Lean Analytics, инвестор и стартап ментор.
Легко взять и потратить бесценное время команды на разработку фич, которые никому не нужны. Особенно эта проблема актуальна для стартапов, время и бюджет которых очень сильно ограничены.
Заблуждается тот, кто считает, что новая добавленная фича сразу заставит людей захотеть использовать весь продукт.
Джошуа Портер, UX директор в HubSpot
Стоит вспомнить интуицию — нашего лучшего «помощника», который постоянно «шепчет» нам на ухо: «Вот эта фича ну точно всех порвет!» И в другое ухо: «А вот эта фича догонит и порвет всех, кого не порвала первая фича».
Мы делаем такие фичи и потом удивляемся, почему вообще ничего не изменилось в продукте.
Известный в Силиконовой долине Marty Cagan в своей книге Inspired выделил три типа менеджеров продукта:
Процесс приоритизации в Hygger
Теперь я хочу рассказать о процессе, который помогает нам в Hygger выбирать будущие фичи и делать продукт все лучше и лучше.
На самом деле, все просто: мы ставим себе цели на 2 месяца, выбираем метрики для контроля, собираем и отбираем идеи, которые могут улучшить эти метрики. Далее мы проводим бережливую приоритизацию идей, делаем скоринг фич, и, наконец, пишем ТЗ на фичи, которые выиграли. Вот и все — фичи готовы к разработке.
Если все это систематизировать:
Формулируем Цели
У нас в продукте есть 2-х недельный trial. Мы хотим увеличить число компаний, которые после триала покупают платную подписку. Это наша основная цель на ближайшие 2 месяца. Также нам нужно отстроиться от конкурентов, ибо на рынке порядка 500 систем для управления проектами.
Выбираем Метрики
У нас есть основная метрика и вспомогательные. Важно, что все эти метрики находятся в нашей зоне влияния.
Основная метрика — конверсия trial-to-paid.
У каждого продукта своя ценность. Например, в Tinder это успешный обмен сообщениями, в Facebook — просмотр непустой ленты в течение какого-то времени.
Пользователей, которые прочувствовали эту ценность мы называем активированными. Наша задача увеличить число таких пользователей. В Facebook посчитали и выяснили, что на активацию влияет число друзей — чем больше друзей, тем больше лента и тем больше времени юзер зависает в ленте и больше рекламы смотрит.
Собираем идеи
Вот главные источники обратной связи для нашего продукта:
Организуем идеи
Так как фидбэка у нас очень много, то мы постоянно наводим порядок в нашем продуктовом бэклоге. Это помогает нам быстро находить нужные вещи и не отвлекаться на ненужные.
Как мы структурируем наш product backlog:
Делаем Lean-приоритизацию
Периодически, по мере накопления новых идей мы оцениваем их с помощью метода Lean Prioritization. Это простая матрица 2×2 c двумя осями — сложность и ценность:
1) Улучшают метрики конверсии trial-to-paid (metrics movers)
2) Помогают привлечь новых пользователей (aha-момент)
Это фичи, которые помогают нам зацепить новых пользователей во время онбординга. Но не нужно забывать про то, что большинство юзеров «отвалиться» уже на второй день. Например, в SaaS отличным показателем для day 1 retention считается 15%. То есть 85% людей попросту уходят на второй день. Поэтому здесь следует думать про фичи, которые увидит как можно больше новых пользователей как можно ближе к моменту регистрации.
3) Помогают удержать старых пользователей
Клиенты купили подписку и теперь просят сделать какую-то фичу. Мы не «бросаемся» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов ее просили. И потом делаем самые востребованные фичи.
4) Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке порядка 500 систем управления проектами. Чтобы выжить и преуспеть, нам нужно делать что-то совершенно новое, желательно кратно улучшающее жизнь пользователей или кратно сокращающее издержки.
Здесь мы ищем фичи, которые могут дать нам конкурентное преимущество, то есть создадут причину, из-за которой клиенты конкурентов придут к нам. Это конкурентное преимущество должно быть уникально, трудно повторимо и, в идеале, не воспроизводимо.
Planning Poker
Для оценки идей мы используем Planning Poker:
Техники приоритизации
Daniel Zacarias собрал в коллекцию 20 техник приоритизации и сгруппировал их по двум свойствам — внешняя/внутренняя и количественная/качественная техника.
Пример внешней количественной техники — модель Кано, где мы даем опросник пользователям. А пример внутренней количественной техники — Lean Prioritization (или Value vs Cost). Я описал этот метод выше.
Скоринг Фичей
Скорим мы не все фичи, а только те, которые выиграли в Lean Prioritization, потому что скоринг — трудозатратная операция.
Мы оцениваем каждую фичу по выбранным критериям, по шкале от 0 до 10. Далее эти значения умножаем на веса и получаем некую финальную числовую оценку, которая позволяет нам сравнивать фичи между собой.
Критерии для скоринга
Вот различные критерии, которые можно использовать для скоринга:
Результаты
Итак, какие результаты принес нам этот процесс:
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл IT-терминов можно, только узнав, как они употребляются
Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.
Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).
Дисклеймер. Все совпадения случайны, а персонажи и ситуации вымышлены. В художественных целях они наделены негативными качествами, поэтому не берите с них пример: это касается как профессиональных качеств, так и отношения к алкоголю, курению и энергетическим напиткам. Также некоторые слова используются и в других сферах.
Новая задача
Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.
Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).
Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).
Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.
Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.
Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.
Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).
На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.
Валидация — проверка данных, которые вводит пользователь.
До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:
— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.
— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?
— Надо проверить в гитхабе историю коммитов.
Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.
Репозиторий — хранилище исходных файлов проекта.
Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.
Говнокод — очень плохой код.
Код ревью — проверка кода.
Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.
Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.
У стола его уже ждал тимлид:
— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.
— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.
— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.
— Но у меня уже есть задача на эту неделю, я не успею всё исправить.
— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.
Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.
Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.
Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.
Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.
Исправление багов
Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.
Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.
Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.
— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.
— Но ты же написал lgtm в комментарии!
— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.
— Ладно, разберусь как-нибудь.
Апрув ( англ. approve) — подтвердить что-нибудь.
Пул реквест ( англ. pull request) — запрос на подтверждение коммита.
LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.
Осталось всего два дня, чтобы исправить баг и добавить новую фичу, а у Вани не было почти никаких продвижений. После работы он, как обычно, зашёл в магазин, но вместо энергетиков решил взять пиво, потому что вспомнил о Пике Балмера.
Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.
Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.
Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.
Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.
— Я разобрался с багом.
— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.
Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.
Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.
К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.
JavaScript — язык фронтенд-разработки.
Помучившись день, он всё-таки закончил. Тимлид оценил усилия:
— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.
Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.