Вперше в Україні! Jeff Atwood, founder @ Stackoverflow — на конференції Highload fwdays
×Закрыть

Первые шаги в DevOps: с чего начать знакомство

Всем привет! Меня зовут Дима, я «наовертаймил» уже 14 лет опыта в IT, 8 из которых — проповедуя непосредственно DevOps и занимаясь в основном проектами, так или иначе завязанными на активном использовании методологии и «тулсэта».

Проработав немало лет в индустрии, я с уверенностью могу сказать, что DevOps — не профессия, это подход к работе и жизни в целом. Если вы хотите стать DevOps-инженером просто потому, что это популярно, наверное, шансы стать PRO не очень велики. Наслаждаться работой вы уж точно будете не сполна. Что хуже, ваши коллеги и руководитель уж и подавно не будут или будут, но недолго :) Так что сначала не помешает разобраться, что же стоит за этим понятием, с какого рода задачами работают DevOps-инженеры. Кому нужно, тот задумается о подобном витке в профессиональной жизни и с чего начать этот путь.

DevOps — профессия или часть обязанностей?

Итак, кто такой DevOps-инженер или кто может им стать? Могу точно сказать, что не существует общего профиля DevOps-специалиста. Каждый отдельный профессионал отличается с точки зрения технической экспертизы и опыта построения специфических систем. Конечно, есть определенный спектр навыков и знаний, общий для всех: DevOps-инженер должен нести, как знамя, и передавать в массы Software Development Life Cycle (SDLC), а еще — отлично ориентироваться в процедурах внедрения изменений в компании (это то, что широкие массы называют инновациями).

Например, на курсах нашей академии мы в первую очередь учим кандидатов координированной работе над единым проектом, спроектированным на основе одного из текущих актуальных проектов компании, но в упрощенном, адаптированном виде (и без нарушения NDA, естественно). Лишь после осознания подходов и выработки умения на практике выстроить рабочий процесс с только что сформированной командой поступивших на курсы молодых специалистов мы начинаем толкать их в сторону осознания и использования технических средств.

Условную техническую базу вполне спокойно наши студенты подтягивают в академии за несколько месяцев, но сама по себе она не имеет смысла без понимания, ЗАЧЕМ это всё великолепие нужно бизнесу.

Вторым важным требованием к DevOps-инженеру являются хорошо развитые soft skills. Ты должен уметь взаимодействовать с командой, понимать мотивацию и проблемы каждого из сотрудников, уметь доносить и «продавать» свою идею так, чтобы зажечь свою команду на внедрение изменений (aka innovations). В придачу ко всему этому ты должен уметь планировать, расставлять приоритеты и активно подключаться к процессу реализации. Неприемлема ситуация, когда DevOps «научил как надо» и ушел дальше думать, кого и чему бы еще научить. Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности. Чтобы действительно приносить плоды, культура должна жить на всех уровнях команды и организации.

Итак, вы дочитали до этого места, и вам кажется, что пробил час, пора двигаться именно в этом дивном (пару лет назад даже хайповом) направлении. Что же делать?

Для начала вы должны стать как минимум специалистом в одной из IT-сфер middle-уровня с хорошей технической базой, soft skills и сильным желанием мыслить стратегически. Затем неплохо было бы подумать, есть ли у вас желание развивать в себе «менеджерский функционал» и при этом не отказываться от сильной технической части. Подумали? Оценили свой текущий уровень? Если уверены в своих силах, давайте читать дальше :)

Кстати, если вы еще новичок в IT, трезво оцените свои силы, рано вам еще в DevOps. Рановато вам учить других и помогать проектам двигаться в светлое будущее за счет своего опыта. Но почитать и понять для себя, о чём эта методология, смысл есть.

«Сначала была теория»

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

Святая обязанность методологии DevOps — находить золотую середину и всегда двигаться от потребностей бизнеса, всячески избегая пробуксовки в тех самых пресловутых направлениях «чисто дев» и «чисто опс». Идеальный продукт, как говорится, — никогда не выпускавшийся продукт. DevOps-специалист обязан очень хорошо ориентироваться как в архитектурных, так и в бизнес-практиках; думать сначала стратегически, и лишь потом уже тактически; понимать закономерности и методологии.

Очень мало смысла перечислять книги и ресурсы, которые рекомендуются новичкам. Это всегда индивидуально и зависит от уже приобретенного опыта. Очень опытные ребята обычно предлагают следующие must have:

  • Phoenix Project — прочтением этой книги принято хвастаться и обсуждать её содержимое в celebrity-кругах DevOps;
  • DevOps handbook — практические советы и опыт;
  • Site Reliability Engineering — а вот тут вы сможете понять, что «мы в ответе за то, что создали», да и вообще, посмотреть, как работать не за еду или идею;
  • Continuous Delivery — несмотря на то, что книга написана в 2008 году, ее актуальность для многих команд и компаний остается очень высокой;
  • Release it! — отличное и легкое чтиво о том, как правильно или неправильно подходить к релизу программного обеспечения;
  • Lean Software Development — качественные рекомендации по поводу оптимизации процессов и культуры waste-анализа в целом, для того чтобы избежать груды ненужной работы, которая рушит святое — магию девелопмента;
  • множество других книг, которые можно найти тут.

Мир меняется

В современном мире новые подходы постоянно абсорбируются и добавляются в список обязательных требований в выполнении обычной ежедневной работы. Ведь когда-то Agile/Scrum были модными фишками, и были весьма распространены отдельные роли «мастеров» ведения этих практик в командах. Теперь же вся ответственность лежит на плечах разработчиков, просто добавилось дополнительное требование. Это нормальная ситуация — инфляция навыков и умений. Чтобы не стоять на месте, нужно очень быстро бежать за технологиями и методологиями.

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

Инициатива не наказуема

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

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

Научитесь учиться

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

  • Например, Олег ведет замечательные дайджесты по DevOps;
  • telegram-канал devopsengineer;
  • Medium, например;
  • Reddit;
  • Slack — ukrops.club;
  • Skype DevOps UA (пригласить может другой участник чата, можно писать напрямую nonflet с просьбой добавить) — здесь еще ни один вопрос не остался без ответа. Так что, если нужен совет или просто хотите пообщаться, обязательно загляните сюда;
  • конференции, например FWdays Highload, DevOps Stage, XP Days.

Вывод

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

К чему я это? А к тому, что мы должны постоянно расширять спектр доступных нам знаний и умений. Именно это увеличит число опций для принятия нами решений. К примеру, вас заставляют работать в стесненных условиях унылого проекта, а вы взяли и ушли в другую компанию DevOps’ом. Конечно же, это шутка :) В идеале нужно нести свет и учение в массы, ведь все мы живем в тех условиях, которые сами себе и создали (или мы просто just fine with it).

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

LinkedIn

63 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Да я просто создан для этой работы!!!

Походив несколько дней, подумав пришел к тому что мысли автора имеют смысл, пусть не всегда корректно как по мне озвученные в статье — мне как и я думаю и многим коллегам, кто прокачивает бекгрануд скилы сложно принять тот факт,
что нам еще «вруливают» управленческие функции. Так же порылся в вакансиях некоторых USA предложений, был несколько удивлен тем, что даже крупные компании ищут инжинеров не только с техническими скилами, а еще и с управленческими. Что наводит на мысли о правоте автора. Так что извиняюсь за резкий тон своих выскзываний.

Вот именно ради таких выводов я статью и написал :)

В принципі жорстка типізація обов’язків прерогатива галер, або контрактників. Якраз великі контори, якщо наймають в штат а не на контракт, то звертають посилену увагу на софт скіли.

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

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

DevOps — не профессия, это подход к работе и жизни в целом.

Автора пристрелить, статью удалить.

И Вам хорошего дня :)

Именно в таких нюансах есть огромная разница между «девопс» и DevOps Engineer

Phoenix Project — прочтением этой книги принято хвастаться и обсуждать её содержимое в celebrity-кругах DevOps;

Ок, заказал. Не потому, что мне так интересна тема DevOps. Просто абсолютно все знакомые мне девопсы — это заядлые алкаши и наркоманы и с ними весело проводить время.

Так і не зрозумів справжній сенс написання цієї статті.((
Для кого вона?

Для реклами курсів. Вийшло правда не дуже, раз ви не зрозуміли справжніх намірів.

Ага, а ще реклами тематичних чатів і книжок ( ви ж купите, правда? )

Треба ж було хоч щось додати шоб вся стаття не виглядала як shameless plug.

Ви мене викрили! Піду вимагати свої 20 баксів за рекламу

Первые шаги в DevOps: с чего начать знакомство

Очікування:

Так епта, AWS GCP, про Docker не забыть, k8s, тааак, падажи емана...

Реальність:

Вчіть софт скіли, читайте бложики, приходьте до нас в академію

Академія опціональна, все інше тру :)

Я чомусь думав, що клауд-інженер — це зовсім окрема компетенція, не кажучи вже про диригента-оркеструвальника. Чи зараз простий запуск інстанса з контейнером вже вважається опсом?

А ви походу з тих хто ділить людей на кодерів, программістів та інженерів?

Зважаючи на історію ваших постів, це трошка некоректний докір. Звичайно можна знати всього по троху — але деякі сторони почнуть і будуть переважати.

Обколються по під’їздах своїми клаудами і потім отримують сертифікати «диригентів-оркеструвальників» та «клауд інженерів».

Я ділю людей за рівнями освіти.

Є профтехосвіта. Люди навчаються нескладних виробничих навичок. Класти цеглу, точить гайки, писать класи.

Є інженерна освіта. Люди навчаються складних, але стандартних виробничих навичок. Проектувати зручні та безпечні домівки чи автівки, або літаки чи софтверні системи відповідно до норм.

Є аспірантура-докторантура. Люди навчаються складних теоретичних навичок. Наприклад, розробляти системи, яких не розробляв ще ніхто раніше. Знаходити методи, про які раніше ніхто не знав. Доводити коректність своїх суджень та висновків. Створювати норми, за якими потім працюватимуть інженери, проекти яких реалізуватимуть техніки.

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

Я ділю людей за рівнями освіти.
ІТ, де просто нема адекватних навчальних закладів

Ясно.

Є аспірантура-докторантура. Люди навчаються складних теоретичних навичок. Наприклад, розробляти системи, яких не розробляв ще ніхто раніше.

))))))))))))))))))))))))))))))))))))))

ок )))))))))))))

Неповне цитування — один з різновидів брехні. Я написав —

ІТ, де просто нема адекватних навчальних закладів рівня, вищого за ПТУ

А що так насмішило? Як ви вважаєте, хто зараз майструє стелларатори в локхіді? Випускники «академії» ШАГ?

А що так насмішило?

Шо наша розмова проходить в контексті девопсів,.

Девопс курильщика и девопс здорового человека

Хорошие книжки, интересные.

DevOps — не профессия, это подход к работе и жизни в целом.

Прямо як хіпстерство.

Жизненный цикл всех IT направлений так или иначе проходит через хипстерство :)

Это только если смешивать работу и личную жизнь

Ты должен уметь взаимодействовать с командой, понимать мотивацию и проблемы каждого из сотрудников, уметь доносить и «продавать» свою идею так, чтобы зажечь свою команду на внедрение изменений (aka innovations). В придачу ко всему этому ты должен уметь планировать, расставлять приоритеты и активно подключаться к процессу реализации. Неприемлема ситуация, когда DevOps «научил как надо» и ушел дальше думать, кого и чему бы еще научить. Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности. Чтобы действительно приносить плоды, культура должна жить на всех уровнях команды и организации.

А ПМ и Техлид зачем тогда ?

Девопс — це коли нема техліда, SE/SA, а є тілько деви, які ще трошки опсять. І швєц, і жнєц, і на дудє ігрєц, і на жабє пісєц, і енжинксу конфігі крутєц.

Тогда это сисадмин, а не девопс.

А якщо в основному на жабі пісєц — то вже девопс.

Не, имхо статья — бредни. Ну если уже и придумали это понятие DevOps, если себя так называешь — ну хотя бы стоило открыть сертификацию Амазона да посмотреть как Амазон считает и какие требования выдвигает. Если даже признать правоту статьи да + ваш первый коммент выходит что DevOps это такой ПМ + Техлид, за которого не хотят платить столько сколько стоит хороший тех. лид + еще и ввязавшийся в ПМы.

Девопс — це для малих груп, де накладно тримати окремих техліда/системщика. Береться стандартно-типова квадратно-гніздова платформа для деплоя, і вважається, що всі у групі з цією платформою можуть впоратися — від розвороту в дефолтній конфігурації до нескладного адміністрування — додати юзерів, виставить права, прописать таргети етц. Все, що поза можливостями платформи, або навіть виходить за межі 10% найбільш вживаного-популярного, розписаного по хаутушках — вже «неможливе».

Стаття, власне, напирає на тому, що треба вивчать можливості обраної платформи і нести здобуте знання в групу. Думка слушна, але занадто тривіальна, аби виносити її в цілу статтю. Звичайно, якщо метою статті не була реклама академії софтсерва.

хех. С учетом подачи инфы, отсутствия связи с реальным миром, то все таки наверное соглашусь.

Звичайно, якщо метою статті не була реклама академії софтсерва.

Тогда это оправдывает бредни.

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

Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности.

Это не посыл — это навязывание. Так же вы не отетили в контексте вашей статьи, для чего в проекте нужен ПМ и Техлид ?

А смысл мне отвечать, если Вы навязываете конфликт? Если у человека в профайле уаазано DevOps & SRE , то такой вопрос не должен возникать. На этих позициях люди УЖЕ умеют в понимание бизнес процессов. Ну а если не умеют — то им зря платят з/п за эту должность, увы.

Вопросом на вопрос, понятненько....

Ну, це називається «інфляція». Неможливо продовжувати робити приблизно однакові речі і не втрачати вартість на ринку праці. Це стосується не тільки DevOps.

Вся історія людства, його прогресу — це історія спеціалізації. Від натурального виробництва всього, що вдається, для власного споживання — до товарного виробництва на обмін/продаж. Чим вищий рівень спеціалізації — тим вище рівень доданої вартості.

Кому з лікарів ви довіритесь — тому, хто займається виключно медициною, чи тому, хто третину часу витрачає на дачне вирощування картоплі для власного прокорму, а ще третину — на перекриття дірявого даху та інші роботи по дому?

Кому ви довірите ремонт свого авта — автомеханіку, що заробляє виключно діагностикою та ремонтом машин, чи дяді васі, який за пляшку готовий хоч асфальт утоптувать, хоч двір підмітать, хоч колінвала молотком рівнять?

На жаль, наші ряди не стають тіснішими від ширини наших профілів. «Широкий профіль» — це «всього потроху», а не «все на відмінно». Для малобюджетних проектів, де не вистачає грошей на окремих техліда/архітекта/сисадміна можна обійтися і широченними профілями, але й результат буде відповідний. Інколи це прийнятний розмін ціни на якість, і для носіїв широченного профілю безумовно є ринковою перевагою перехід від «всього потроху» до «всього потроху+». Але суть концепції це не міняє.

Ви змішуєте поняття. Я кажу про те, що всередині одного профайлу відбувається розмиття і постійне збільшення кількості під-компетенцій. Покажіть, наприклад, високооплачуваного «просто джава програміста». Ви впевнені, що він просто пише чистий джава код і більше нічого не робить?

Я, якраз, нічого не змішую.
В Козьми Пруткова є підходящий віршик:

Раз архитектор с птичницей спознался.
И что ж? — в их детище смешались две натуры:
Сын архитектора — он строить покушался,
Потомок птичницы — он строил только «куры».

«Строить куры» — це те, що згодом називалося «крутить шашни».

Девелопер є девелопер. Сисадмін є сисадмін. Якщо змішать ці дві спеціалізації, то не вийде девелопера-сисадміна. Вийде девопс.

Девелопер є девелопер. Сисадмін є сисадмін. Якщо змішать ці дві спеціалізації, то не вийде девелопера-сисадміна. Вийде девопс.

тут как бы в статье подача идет что сюда же примешаивается менеджерские качества — пм + тех. лид. Что дает вообще веселую юшку — я и пахарь, я и бык, я и баба, и мужик...

Никто не запрещает быть исключительно пахарем или быком или бабой ну или мужиком. Каждый выбирает для себя, кем/чем хочет быть

Никто не запрещает быть исключительно пахарем или быком или бабой ну или мужиком. Каждый выберает для себя, кем/чем хочет быть

не вяжется с

Ты должен уметь взаимодействовать с командой, понимать мотивацию и проблемы каждого из сотрудников, уметь доносить и «продавать» свою идею так, чтобы зажечь свою команду на внедрение изменений (aka innovations). В придачу ко всему этому ты должен уметь планировать, расставлять приоритеты и активно подключаться к процессу реализации. Неприемлема ситуация, когда DevOps «научил как надо» и ушел дальше думать, кого и чему бы еще научить. Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности. Чтобы действительно приносить плоды, культура должна жить на всех уровнях команды и организации.

Но это имхо, что мне сертифицированному понимать в тонких материях....

Чего не вяжется? Не хочешь действовать DevOps-like — не называй себя таковым и делов то. Никто ж не против.

DevOps-like

А это как ?

не называй себя таковым и делов то.

Так я и не называю, меня так назвали после сертификации.

Чего не вяжется?

Не вяжется то, что вы пишете про «должен», «святая обязанноять» и полный атас

кого и чему бы еще научить.

Это все не вяжется с:

Никто не запрещает быть исключительно пахарем или быком или бабой ну или мужиком. Каждый выбирает для себя, кем/чем хочет быть

Если можна не быть пм, тех.лид, скрам мастер, прогер, тестировщик, сисдамин в одном лице, зачем вы пишете что подобные вещи «must have» ?

Одно дело как выше писал человек — когда проект голый, денег мало, ищут толкового технаря что бы разгребал и был «все в одном», другое озвученные вами тезисы, без огласки на подобные условия. Я потому и спросил у вас, если в проекте есть ПМ + Тех. лид, зачем это все девопсу ? Зачем человеку которого ориентируют на сильный бекграунд скилы в умении пинать людей в команде в направлении инноваций, планировать работу команды, ставить сроки и прочее... ?

Если я и говорю про девопс — то в разрезе этого понятия в том же Амазоне — они сертифицируют. Если я говорю про SRE то хотя бы в разрезе Гугла — они клинжку выпустили хорошую. Ну и это такие компании которые дело говорят, дают инструменты и практики на которые опираются обычные смертные. А у вас как то все в кучу получается, еще и с эпитетами от которых лично меня бомбит.

Дима, простите, я не обладаю достаточным уровнем знаний и опыта для продолжения этой беседы.

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

Та я свій перший код написав на фортрані ще в 1987 році :) І з того часу куди тільки не дивився, в яких тільки проектах не брав участь. І, власне, до 2010 року більше спеціалізувався саме на SE/SA. Але потім відчув, що ДБА гріє найбільше, а сисадмінство дедалі стає менш оціненним та ліквідним. Підозрюю, що саме через зниження попиту на СЕ/СА виник дефіцит кадрів на цьому ринку, який зараз намагаються компенсувати перекладенням того функціоналу на девів. Ну, буває, успіхів і всьо такоє. Але коли я по старій пам’яті залізаю на терени девопсів, то мені стає дещо моторошно :) Можливо, індустрія згодом дійде до розуміння неможливості сисадмінить на півшишечки, у вільний від девелоперства час, але мені те вже нецікаве.

Ну, тут все насправді гірше — все рухається в бік NoOps та Performance Engineering.
Так що методології необхідні не для змішування обовьязків, а для адаптації до чудового лампового «завтра»

але рекрутери будуть вперто питати про це :))

Ну, такоє. На тому сегменті ринку, де орудують ті рекрутери — нехай.

Ага ага, кожного разу так відмахуються рукою на зміну тенденцій. А потім від кожного очікують знання купи страшних технічних речей і якісь архітекти пишуть статтю «Перші кроки в $хіпстерський_термін »

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

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

А є сегменти, де вигідніше найняти одного SE/SA, одного ДБА і десяток девелоперів, які будуть займатися саме девелопом. Як то кажуть, на кожен товар є свій покупець.

Кошерная статейка.

Подписаться на комментарии