Содержание
- Не одним JS единым! Пройдёмся по процессу разработки.
- Формируя профиль бесперебойного продакшена
- From hard skills, to soft skills.
- Начнём с Web разработки 🙂 Отличие Java от JavaScript уже знают все, а вот отличия «фронта» от «бэка» — единицы.
- Возможности для отстройки
- «Какая разница? Вы же тоже сайты делаете?»
Не одним JS единым! Пройдёмся по процессу разработки.
Юзабилити (от англ. «usability») – показатель того, насколько тот или иной продукт/интерфейс удобен для пользователей.
В сайте, который сделан по всем канонам юзабилити, пользователь на раз-два находит нужную информацию, легко ориентируется в навигации страниц и разделов и в целом получает удовольствие от времяпрепровождения на ресурсе. К примеру, юзабилити веб-сервиса строится по следующим принципам:
- Удобный дизайн
- Логичный и структурированный контент
- Общение с пользователем
- Возможность отмены действия
- Ненавязчивые предложения помощи
- Все возможности на виду
Часто за юзабилити приложения отвечает UI/UX Developer. Он ответственен за применение принципов интерактивного и визуального дизайна на веб-сайтах и веб-приложениях для обеспечения положительного и связного взаимодействия с пользователем.
Рисёрч (от англ. «research») – попросту говоря, изучение определенной темы. Задача сделать «рисёрч» в джуниорском айтишном сленге подразумевает необходимость самостоятельно разобраться с темой.
Парсить (от англ. «parse») – собирать и обрабатывать данные. В среде разработчиков термин может обозначать поиск и систематизацию информации, размещенной на определенных сайтах, с помощью специальных программ, автоматизирующих процесс.
Мержить (от англ. «merge»). Речь идет об объединении или слиянии веток кода. В ногу с этим термином идёт ещё один — коммитить, и часто между ними возникает путаница. Закомитить означает залить свои изменения (свой код) в ветку, в то время как замержить — объединить свой код с чужим (с другими коммитами).
Деплой (от англ. «deploy») – многоступенчатый процесс переноса кода на сервер или устройство, где он должен функционировать. В ходе деплоя происходят следующие этапы (ниже приведем один из простейших примеров):
- Код подгружается на сервер
- Ставятся все зависимости, которые необходимы
- Выполняется сборка, а после нее — миграции (к примеру, меняется структура базы данных с помощью SQL-скриптов)
- Запускается обновленная версия кода
Продакшн (от англ. «production») – версия сайта, программы или приложения, в которой устранены все ошибки и которая доступная конечным пользователям.
Аутсорс (от англ. «outsourcing») – выполнение определенных функций/задач компании внештатными специалистами. Например, iTechArt является аутсорс-компанией. Наши сотрудники разрабатывают программное обеспечение для заказчиков из Западной Европы и США.
Легаси-код (от англ. «legacy code») – код, который устарел или по какой-то причине больше не поддерживается, но всё ещё используется.
Нативный (от англ. «native») – не измененный и не модицированный. В разработке чаще всего используется в сочетании «нативный код», т.е. исходный. Нативные приложения (англ. native app(lication)s) – это прикладные программы, которые были разработаны для использования на определённой платформе или устройстве. Например нативные приложения для iOS написаны на Swift или Objective-C, а для Android написаны на Kotlin или Java. Apple и Google предлагают разработчикам приложений собственные инструменты разработки, элементы интерфейса и стандартизированный SDK; Xcode для iOS и Android Studio для Android
Код-ревью (от англ. «code review») – систематическая проверка кода одним или несколькими рецензентами на предмет ошибок, не обнаруженных на этапе написания кода. В процессе код-ревью устраняются ошибки в форматировании строк, утечка памяти, переполнение буфера и др.
Рефакторинг кода (от англ. «refactoring») – переработка исходного кода, которая призвана сделать его «чистым», облегчить его понимание и последующую поддержку. Чистый код имеет следующие свойства:
- Проходит все тесты, разработанные специалистами по тестированию;
- Понятен для других программистов: в коде появились уточняющие комментарии о том, что именно значит та или иная строчка, стиль оформления программы соответствует общепринятым правилам;
- Не содержит дублирования кода;
- Содержит минимум классов и других движущихся частей.
Если следовать этим свойствам, то на выходе мы получим Чистый код который легче и дешевле поддерживать 🙂
Для более подробной информации советую прочесть Clean Code за авторством Robert C. Martin
Формируя профиль бесперебойного продакшена
Пытаясь «нащупать» преимущество и закрепить его на практике, мы сформировали для себя некий манифест, который в той же степени может быть использован любым аутсорс-продакшеном, стремящимся к званию «бесперебойного». Только нужно понимать, что это не просто список теоретических установок, а конкретный план к действию. Если в вашей компании по какому-либо из пунктов отсутствуют реальные изменения/апгрейд, можно считать, что вы его полностью пропустили.
1. У вас должно быть достаточное количество производственных ресурсов. Имея на руках 2 разработчиков, которые будут выдавать на выходе 200–250 «чистых» человеко-часов, вы вряд ли сможете удовлетворять потребности даже нескольких агентств с более-менее серьезными объёмами работ. Соответственно, нужно ориентироваться как минимум на 10 штатных специалистов, чтобы представлять собой хоть какой-то серьёзный «производственный цех».
2. Ключевые бизнес-процессы должны быть отлажены на «5+», дабы минимизировать влияние пресловутого человеческого фактора. Под ключевыми мы понимаем:
a. найм сотрудников (мы решили этот пункт с помощью создания HR-воронки в Битрикс24);
b. обучение сотрудников. У вас должны быть четкие структурированные программы адаптации и повышения квалификации, и каждый этап обучения должен заканчиваться аттестацией/тестированием;
c. документооборот. Мы не поленились и выделили для этого направления в команде отдельного человека, который регулярно улучшает свои знания, проходя обучение
Потому что договора, счета и акты в случае работы двух digital-компаний — это супер-важно.
d. стандарты работы для производства. Вы должны уметь работать не только по накатанной схеме, но и гибко адаптироваться под любой SLA (по крайней мере в разрезе отдельной проектной команды);
e. оценка проектов/расчет смет. Наличие в штате специалиста, который умеет оценивать проекты даже самой высокой сложности + чёткая инструкция для расчёта сметы на основе шаблона;
f. выявление и исправление багов на раннем этапе. Наличие в штате QA-специалиста. Предоставление гарантий на отсутствие багов в момент сдачи проекта конечному заказчику.
3. Стабильное ценообразование — любые частые «переиндексации» ставок в сторону их увеличения плохо воспринимаются генподрядчиками. Старайтесь избегать их.
4. Порядок в CRM и безукоснительное соблюдение правил регулярного менеджмента. Если списки задач ваших сотрудников находятся в неактуальном состоянии, то это прямая дорога к бессистемности и производственным перебоям.
5. Чёткий трекинг всех этапов реализации проекта + взятие на себя ответственности за низкоуровневый менеджмент задач.
6. Возможность подключения топ-менеджмента для оперативного решения нестандартных задач. Работа с агентствами подразумевает, что многие вопросы решаются между руководителями, и иногда это нужно делать буквально «на лету». Это не тот случай, когда между двумя структурами должна быть многоступенчатая прослойка менеджеров, каждый из которых вносит свою лепту в ухудшение коммуникаций.
Важно: вы должны быть готовы подтвердить любое свое заявление, потому что ваши коллеги никогда не поверят в пустые обещания, не подкреплённые фактами.
From hard skills, to soft skills.
Хард скиллы (от англ. «hard skills») – професссиональные компетенции IT-специалиста (языки программирования, протоколы и стандарты, системы анализа и т.п.). Наиболее популярные технологии для программистов на июнь 2021 года можно найти на index | TIOBE — The Software Quality Company.
Софт скиллы (от англ. «soft skills») – компетенции специалиста, которые помогают ему взаимодействовать с коллегами
На стажировках в Students Lab большое внимание уделяется различным софт скиллам, таким как коммуникативность, проактивность, ответственность и самостоятельность. Перед началом занятий менторы проходят специальные курсы для оценки и развития навыков и во время стажировки помогают стажёрам улучшить свои софт скиллы
Нетворкинг (от англ. «networking») – это целенаправленное расширение сети контактов (личных и профессиональных). Нетворкинг способствует максимально быстрому и эффективному решению бытовых и бизнес-вопросов. Его основа – доверительные и долгосрочные отношения людей, основанные на взаимопомощи.
Начнём с Web разработки 🙂 Отличие Java от JavaScript уже знают все, а вот отличия «фронта» от «бэка» — единицы.
Фронтенд (от англ. «frontend») — то, что считывается браузером и демонстрируется (запускается) на экране пользователя (CSS, HTML, JavaScript). Речь о самих страницах сайта и связанных с ними элементах – таблицах, кнопках, рекламных баннерах, формах обратной связи и прочем.
Бэкенд (от англ. «back-end») – серверная, иначе говоря, внутренняя часть сайта или приложения. Обычно она отвечает за сохранность и обработку данных. К этой программной части пользователь доступа не имеет. В работе с бэкендом в ход идут языки программирования типа Python, Ruby, Java, PHP, C#, Swift и проч., а ещё системы управления базами данных MySQL, PostgreSQL и др.
Фулстек-разработчик (от англ. «full stack developer» или «full stack engineer») – специалист, который в равной степени способен работать как с внешним, так и с внутренним интерфейсом веб-сайта или приложения. То есть фулстек-разработчики могут заниматься проектами, которые включают базы данных, создание веб-сайтов, ориентированных на пользователя, или даже работать с клиентами на этапе планирования проекта.
Фреймворк (от англ. «framework») – в буквальном смысле программный «каркас» или шаблон, который разработчик наполняет своим кодом. Фреймворки помогают собрать воедино разрозненные куски приложения/программы, повышают скорость и удобство разработки.
В веб-разработке самыми популярными фреймворками являются React, Angular, Vue.js и Node.js.
Кстати, если у тебя есть базовые знания JS и небольшой опыт разработки Web приложений, то прямо сейчас можно подать заявку на стажировку Junior Full-stack JS Developer, где как раз изучаются все самые популярные фреймворки на проектах приближенных к реальным. Не упусти свой шанс стать Junior JavaScript разработчиком уже сейчас!
Возможности для отстройки
На первых порах становления рунета рынок субподряда в области веб-разработки практически отсутствовал. Почти все пытались организовывать производство собственными силами. Спустя 20 с лишним лет ситуация существенно изменилась.
На сегодняшний день можно с уверенностью сказать, что рынок веб-аутсорсинга существует (исходя из нашего последнего исследования, 56,7% digital-компаний в той или иной мере привлекают для реализации проектов другие команды). У некоторых уже сформирована определённая культура обращения за субподрядом.
При этом в строю субподрядчиков постоянно прибавления: всё больше команд пытаются перебраться из клиентского сегмента в наш внутренний, где на первый взгляд живётся намного «комфортнее» и есть множество проектов.
Последний факт действительно можно подтвердить: по крайней мере у нас текущая загруженность даже вынуждает отказывать агентствам, приходящим с новыми запросами.
Но, чтобы быть успешным в этом сегменте рынка, нужно сильное преимущество. И оно должно проявляться не столько в «упаковке» (сайт, КП и другие атрибуты/информационные носители), сколько в «начинке». Того, чьи заявления далеки от реальности, как правило, очень быстро вычисляют. Здесь никого нельзя обмануть: уровень понимания продукта и бизнес-процессов очень высокий, поэтому примитивные психологические «трюки» и маркетинговые триггеры не работают.
Аутсорсинг — одна из немногих частей digital-рынка, где продажа «кота в мешке» (любых непрозрачных услуг) невозможна.
Говоря о преимуществах, чаще всего рассматриваются 3 основные дисциплины (каждая из которых может служить «группой» для целого ряда сильных сторон подрядчика):
- продукт.
- процессы.
- сервис.
И первые два варианта в нашем случае намного опережают по важности/востребованности третий.
Что важно для генеральных подрядчиков, которые хотят усилить экспертизу своей компании.
1. Удерживать высокое качество выполнения работ.
2. Снизить себестоимость / не переплачивать за проект (получать фиксированную оценку стоимости реализации задачи).
3. Масштабироваться.
4. Избавиться от необходимости обучения и контроля сотрудников.
5. Сэкономить времязатраты, чтобы выделить больше ресурсов на развитие других внутренних направлений.
6. Получать помощь в технических вопросах на пресейле.
7. Упростить согласования и коммуникации между всеми участниками проекта.
8. Оставить функцию продюсирования проекта на своей стороне.
9. Получить доступ к большому количеству производственных мощностей.
10. Найти надежного субподрядчика с хорошей репутацией и высокими компетенциями для долгосрочного сотрудничества.
Несмотря на то, что последний пункт является слишком обобщающим, он, по сути, резюмирует все предыдущие и в целом олицетворяет главное требование генерального подрядчика — сделать так, чтобы весь процесс работы проходил без перебоев.
Перебои — это то, чего больше всего опасается агентство, которое приглашает (или не приглашает) вас на проект.
- Перебои с производственными мощностями — это постоянная вероятность того, что в момент, когда нужно будет расширение, агентство останется ни с чем, возможно, даже упустив ценного заказчика.
- Перебои с ценами (повышения рейтов) — это вероятность снижения маржинальности/прибыли в рамках отдельно взятого проекта.
- Перебои с графиком работ — это постоянные срывы дедлайнов, за которые необходимо извиняться перед клиентом.
- Перебои с качеством — это удары по репутации генерального подрядчика (со всеми вытекающими).
Отсюда следует, что любой «перебой» — это зло, страшный сон для генподрядчика.
«Какая разница? Вы же тоже сайты делаете?»
Начать эту историю лучше даже не с отличий, а с непонимания бизнес-модели аутсорс-продакшенов в целом. На рынке периодически звучат высказывания, которые повергают нас в шок. Так, люди не понимают, что мы не «digital-агентство» (даже несмотря на то, что участвуем во внедрении CRM и разработке сайтов). Также есть мнение, что если аутсорс-продакшен не загружен на 100%, то он может легко развернуться и пойти работать на конечный бизнес.
Дабы поставить точку в этом вопросе, перечислим основные отличия самой модели аутсорс-продакшенов.
1. Необходимо больше внимания уделять найму и «выращиванию» сильных специалистов.
2. Сужение компетенций («комплексность» практически недостижима).
3. Фокусировка на 1–2 основных технологиях.
4. Полностью штатное производство. Наличие фрилансеров или субподрядчиков недопустимо — это противоречит сути бизнес-модели (субсубподряд в digital возможен, но это совсем другая история).
5. Строгий контроль качества. На выходе должен быть качественный код, потому что продукт — одна из главных ценностей аутсорс-продакшена.
Как видим, все это довольно далеко от бизнеса digital-агентств. Зачастую с ними может не быть ни одного пересечения по указанным пяти пунктам. В их случае намного важнее сервис, клиентоориентированность, стратегические и аналитические компетенции.
Из всего этого рождается вполне логичный вывод: аутсорс-продакшен априори не может резко трансформироваться в digital-агентство. Это две разные половины мира со своими правилами.
