Проектний етап як сутність Академії

Привіт, я Альона, закінчила Академію в 2017 році за напрямом JS. Дізналася про неї зі статті на DOU.ua у період, коли працювала над власними pet-проектами. Найбільше зацікавило те, що у завершальному етапі ведеться командна розробка проекту під менторством досвідчених розробників, що було дуже актуальним для мене на той момент.

Хочу поділитися з вами своїм досвідом проходження саме цього етапу Академії - написання проекту в команді.

Одне з найголовніших питань, які мене цікавили як розробника-початківця, - де взяти реальний досвід розробки. Самостійно скласти навчальний план, засвоїти базову теорію та стек технологій - задача, яка легко реалізується за наявності бажання та чіткого бачення необхідного результату. Чудово це поєднується зі створенням власного проекту (нехай і невеликого), де можна буде втілити набуті знання. Але навіть після цього я не уявляла, які існують процеси, умови при розробці проекту в команді; які бувають ситуації та проблеми, як їх вирішувати. Я опинилася у замкнутому колі при пошуку роботи: від кандидатів у 99% вакансій вимагався комерційний досвід, який був відсутній та взяти його не було звідки.

Проведення курсів компаніями з метою знайти талановитих джунів набуло популярності за останні роки, але є одне але: вони, у більшості, проводяться онсайт, тобто в офлайн-режимі, що не є варіантом для тих, хто проживає в інших містах. Академія ж надає зручну можливість пройти навчальний курс онлайн і отримати досвід з розробки, максимально близький до реального. Цією можливістю я і вирішила скористатися два роки тому.

Тепер перейду до конкретики та розповім, спираючись на власний досвід, що собою являє останній, найскладніший та найцікавіший етап Академії.

Що відбувається на проекті?

Після закінчення другого, лекційного етапу Академії починається проектний - це розробка проекту в команді з ~10 людей під менторством двох коучів протягом 1,5 місяця. Якщо попередній місяць ми, студенти, здобували необхідні знання за своїм напрямом, то тепер настав час їх застосувати у повному обсязі. У моєму випадку (JS) ми використовували такі технології: Angular + TypeScript, Node.JS + Express, MongoDB, Socket.IO, SASS, Webpack.

Наш напрям JS був поділений на три команди: дві команди, які писали додаток на React, одна - на Angular. Перед розподіленням серед нас провели опитування, кого який фреймворк цікавить більше. До Академії я мала трохи досвіду роботи з AngularJS і, знаючи його кардинальні відмінності від наступних версій, вирішила розібратися з Angular. Якщо говорити узагальнено про відмінності, то перша та наступні версії Angular розрізняються настільки, що не можна просто так взяти та підняти версію на проекті, доводиться переписувати його, починаючи від кореня додатка, закінчуючи кожним окремим компонентом. Завдяки цьому Angular свого часу заслужив “тепле” ставлення у колах фронтендщиків.

Стартували ми у команді з 13 людей, під кінець залишилося 7. Навіть сім людей - це велика команда для створення базового функціоналу додатку, якщо б не один нюанс: більшість із нас не мала майже ніякого досвіду.

Першою нашою задачею було визначитися з тематикою проекту - в результаті ми підтримали ідею коуча розробити фітнес-додаток на кшталт Runtastic, Runkeeper. Придумати назву - одне з найскладніших завдань, як виявилося, бо визначилися ми з нею аж через місяць - proFit.

Коуч склав план функціоналу, який ми мали реалізувати. Одразу скажу - впоралися ми на ~80%, що є чудовим результатом. Що встигли зробити: відстеження спортивної активності та харчування, комунікація (чат, підписка на тренерів, написання статей), створення тренувальних планів, контроль ваги та калорій, досягнення, система подій тощо. Ці можливості були доступні зареєстрованим користувачам в залежності від їхнього типу (звичайний користувач, тренер і адмін).

Наступним етапом (ним займався коуч) було створення завдань на Трелло за категоріями фронтенд, бекенд, research тощо, а також їх розподіл за спринтами. Спринт - це проміжок часу (тиждень у нашому випадку), за який ми мали розробити певний функціонал і продемонструвати його клієнтам (у ролі яких виступали менеджери з Binary Studio) у кінці тижня на weekly meeting. Ця практика є частиною методології розробки програмного забезпечення Scrum, яка широко використовується в комерційній розробці. Вона була вибрана для Академії тому, що при ній ревью додатку проводиться регулярно (наприкінці кожного спринта), що дозволяє контролювати хід розробки, відслідковувати наявні та потенційні складнощі, а клієнт має змогу оцінювати виконану роботу та вносити ідеї/побажання.

Коучі дали цінну пораду: запорукою довгострокового успіху на проекті є порозуміння із замовником. Головний інструмент при роботі з ним - комунікація. Якщо ви розумієте, що замовник вимагає щось таке, що складно реалізується, та знаєте альтернативу - спробуйте донести це до нього. Але також не забувайте, що ви розробляєте продукт для споживачів, як ваш замовник, тому і дивитися на нього треба очима не тільки розробника, але і споживача. Це - базові речі, про які нам регулярно повторювали, і недарма - їх інколи забувають навіть досвідчені розробники.

Таски зі спринту ми могли брати самостійно, хоча зазвичай їх розподіляли на daily meeting, де кожний з нас звітував про зроблену роботу, чи виникали труднощі; обговорювали питання, що могли виникнути. Спринт за спринтом - і ми розробили багатофункціональний повноцінний додаток буквально з нуля. Останні два тижні займалися багофіксом, а в самому кінці - підготовкою до демо.

Презентація готового продукту в офісі відбувалася у форматі “показ слайдів - показ додатку”. Її взяли на себе я та ще один хлопець з команди. Виступати публічно зазвичай не люблять (я не виняток), але це був один з тих моментів, коли я вирішила вийти із зони комфорту та розповісти кільком десяткам людей, яку роботу ми виконали за останній місяць.

Підготовкою слайдів зайнялася я, адже у мене було конкретне бачення, як краще їх оформити. Необхідним мінімумом інформації, яку вони мали включати, були назва проекту, стек, тематика, для кого розроблений, які є аналоги на ринку, який функціонал.

Після слайдів ми продемонстрували безпосередньо додаток, починаючи з реєстрації/логіну. Ми знали, що не обов’язково показувати всі вьюхи до останньої та описувати кожне текстове поле - важливо утримати увагу глядачів основними та найефектнішими штуками, які є сутністю проекту. Перед виступом ми продумали план контенту для демонстрації, перевірили його кілька разів на наявність багів, упевнившись, що ніде не вилізе exception і функціонал повністю готовий.

З якими труднощами можна зіткнутися?

Менеджмент часу

Не пригадаю випадків, коли мені на щось не вистачало часу чи я не вкладалася у терміни. Але є нюанс: на відміну від кількох людей у команді, я не працювала на той момент (за кілька місяців до Академії пішла з основного місця роботи, щоб мати більше часу на самоосвіту, що згодом виявилося цілком правильним рішенням), тож мала змогу займатися проектом цілий день.

Як я вказала вище, ми починали у складі 13 людей, до кінця дійшли 7: хтось не розібрався, не потягнув навантаження, комусь просто не вистачило часу. На мій погляд, якщо ти вже пройшов стільки відборів, присвятив два місяці Академії, то вигідніше буде завершити розпочату справу та пройти останній етап, який, фактично, є головною складовою Академії.

Якщо бажаєте досягти доброго результату, доведеться виділяти мінімум 8 годин на добу. В середньому стільки часу може піти на створення одного компонента з бізнес-логікою або API із певним функціоналом. На початку такі речі можуть займати у вас більше часу, та це цілком нормально: коли проект тільки стартував, я достатньо добре орієнтувалася та без складнощів робила таски на фронті, але з бекендом (написання API, запитів до бази даних тощо) я почала працювати більш-менш автоматизовано через два тижні, бо майже не мала досвіду у цьому напрямку.

Важливо “підтягнути хвости” з теорії та практики якомога скоріше, адже далі буде наростати темп і стане ще складніше.

Буває так, що загальмуєш на якомусь елементарному моменті (не запускається проект, не відображається правильно текст у компоненті), та він стає блокером на певний час. Якщо ж ви мучитеся із ним довше години - звертайтеся по допомогу, бо інакше тільки змарнуєте час і зіпсуєте собі настрій.

Перфекціонізм

Цей пункт частково пов’язаний із попереднім. Будьте готові, що вашу тягу до перфекціонізму (щоб все було піксель-у-піксель) помітять не завжди. Той час, який ви витратили на доведення якоїсь вьюхи до ідеалу, “під лінійку”, можна завжди використати на щось більш корисне - інші таски (які ніколи не закінчуються) або банально відпочинок від них. Якщо мова йде, звісно, не про останній спринт, коли клієнтська частина додатку доводиться до ідеалу.

Іще порада для тих, хто хоче отримати максимально позитивний відгук від ментора та, можливо, бути запрошеним працювати у компанії: на всіх щоденних дзвінках детально розповідайте, що і як ви реалізували. Навіть якщо максимально викладаєтесь, але кажете: “зробила/зробив такий-то компонент, все норм, проблем немає” - ментор не зможе оцінити обсяг виконаної вами роботи та, ймовірно, попросить уточнити, чим конкретно займалися для проекту та чи все вдається.

Комунікація

Ви будете не тільки писати власні компоненти, модулі, але і дописувати чужі, так само дописуватимуть і ваш код. Це означає роботу із людьми. Хтось любить ставити два пробіли, хтось - чотири, хтось надає перевагу arrow function, хтось - звичайним, у всіх код і загальні підходи різні. Визначтеся з ментором і командою щодо загальних речей: це знизить ризик потенційних непорозумінь. Стосовно інших моментів: знаходьте компроміси, не доводячи до конфлікту, який впливатиме на вашу продуктивність і проект загалом.

Висновок

У якості висновку поділюся, чим проходження Академії мені допомогло при роботі на проектах у компанії:

1. Під час Академії я зрозуміла, що не треба витрачати час на суперечки, а тим паче конфлікти стосовно технологій, підходів і нюансів написання коду - такі моменти блокують процеси, призводять до затримок у розробці - в результаті це не вигідно нікому.
2. По закінченню Академії я без проблем змогла почати працювати над комерційними проектами та розібратися в основах їхньої архітектури без складнощів. На перших двох додатках був той самий MEAN-стек, на останньому лише Angular замінився на React, MongoDB - на PostgreSQL.
3. Щоб досягти більшої ефективності, треба звертатися по допомогу. Ймовірно, хтось вже стикався з проблемою, яку намагаєшся вирішити, тож якщо витрачаєш на неї багато часу та застряг на місці - звертайся до інших студентів з команди або до коуча. Вміти вирішувати задачі цілком самостійно - це круто, але інколи на це витрачається нераціональна кількість часу. До того ж час від часу варто спілкуватися з коучами, щоб вони розуміли твій прогрес і, за необхідності, могли дати пораду.
4. Як я вище зазначила, я викладалася при розробці фітнес-мережі на всі 100%, але тематика не була захоплюючою для мене. Те саме буває і на реальних проектах, що є цілком нормальним. Тому для того, щоб працювати із задоволенням, варто знаходити для себе цікаві деталі, чи то функціонал, чи то компонент, з якими буде приємно працювати, при цьому залишаючи простір для розвитку, аби не “топтатися” на одному місці.

Що я отримала від Академії у кінцевому підсумку? Досвід, причому унікальний: це була не просто робота із набором фреймворків та інших технологій, але і проходження повного циклу розробки продукту у команді.

Якщо у вас є знання, які ви бажаєте конвертувати у практичні навички, та готові плідно працювати три місяці, наближаючись до своєї мети, - Академія для вас.