IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит

● Full-stack-разработчик — это специалист, который разрабатывает и интерфейсы, и внутреннюю логику продукта. Интерфейс — это, грубо говоря, то, что видит пользователь: например, заходя на веб-сайт, мы будем наблюдать разнообразные элементы, которые реагируют на нажатие, или просто мигают, или выскакивают нам навстречу в неожиданный момент. Внутренняя же логика — это код, который скрывается за этим фасадом и обеспечивает внутреннюю работу всей системы: пользователь эту «подводную утробу парохода» не видит. Например, нажав на эту или иную кнопку, мы видим всплывающую форму, но не видим, как это произошло: как система обратилась к базе данных, нашла нужную информацию и показала ее нам. Чаще всего фронтендом и бэкендом занимаются разные люди, но случается и так, что один или несколько универсальных специалистов делают всё.

● Frontend-разработчики — специалисты, которые создают клиентскую часть продукта, то есть то, что мы, пользователи, видим на веб-странице или в приложении.

● Backend-разработчики, соответственно, работают только над внутренней логикой.

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

4-й этап. Тестирование — как и следует из названия, на этом этапе проводится детальная проверка системы на работоспособность и соответствие всем предъявляемым требованиям. Оно может быть ручным или автоматизированным, и в обоих случаях в нем принимают участие тестировщики. (О них мы поговорим в отдельной главе.)

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

Обычно процесс внедрения происходит следующим образом:

1. Документирование информации о софте — написание инструкций, которые помогут пользователям и другим разработчикам эффективно общаться с этой новой «сущностью».

2. Непосредственно внедрение системы: та самая интеграция нового ПО в уже существующее.

3. Анализ состояния ПО в новой инфраструктуре: вдруг что-то работает не так, как задумано.

4. Если ошибки выявлены, то специалист по внедрению привлекает разработчиков, чтобы те всё исправили.

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

Внедрение нового ПО — важнейший и во многом стрессовый этап для пользователей. Без грамотного проводника в новые возможности софта такое обновление может стать шок-контентом для всех сотрудников компании. Просто представьте: к вам приходит некто, сообщает, что теперь вместо 1С у вас установлен, скажем, 2С, который вы никогда в глаза не видели, — и гордо удаляется. Ситуация жуткая! На этом этапе пользователям необходима грамотная помощь и регулярное взаимодействие со специалистом.

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

● Первая линия (или HelpDesk) — решают самые простые задачи пользователей: выключите и включите компьютер — заработало? Поздравляю!

● Вторая линия — здесь в работу включаются системные администраторы. Они решают вопросы управления доступом и могут корректировать настройки системы.

● Третья линия — специалисты, решающие сервисные вопросы. Они могут поправить ошибку в коде.

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

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

Глава 8 Методологии разработки в IT