Бережливый аналитик: виды потерь в работе аналитика и способы устранения

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

В докладе я хочу рассказать о бережливом производстве в работе аналитика.

Обычно, когда говорят, что человек ленивый, в это вкладывают какой-то негативный подтекст. Но если немного вдуматься, то слово «ленивый» можно заменить на слово «энергосберегающий» – когда человек старается экономить свой ресурс, делать задачи максимально эффективно, при этом не тратя время на всякую ерунду.

Термин «бережливое производство», Lean – появился давно, но в Россию он пришел где-то в 2010-2012 году. Тогда в различных компаниях появились целые отделы, которые между собой называли «линяторы» от слова Lean – они занимались внедрением “бережливого производства”.

Если внимательно изучить концепцию бережливого производства, то можно увидеть, что она отлично подходит и к оптимизации работы аналитика.
В докладе мы поговорим:

• Что такое бережливое производство, насколько оно применимо к работе бизнес-аналитика.

• Рассмотрим, какие виды потерь возникают в нашей деятельности, исходя из методологии Lean.

• Посмотрим, как их можно устранять.

8 видов потерь в Lean

Бережливое производство ориентировано на устранение в процессах неизбежно возникающих потерь – всего того, что мешает повысить ценность продукта, производства и так далее.

В методике Lean выделяют 8 видов потерь.

• различные лишние переключения, лишние движения;

• создание запасов;

• перепроизводство;

• чрезмерная обработка (обратите внимание, что перепроизводство отличается от чрезмерной обработки, отличия рассмотрим дальше);

• дефекты;

• неиспользуемый человеческий потенциал – один из моих любимых видов потерь;

• ожидания;

• и транспортировка.

Вернее, так: разные школы выделяют либо 7, либо 8 видов потерь. Но мы пройдемся по классическим 8 видам, а потом я покажу, как это работает в деятельности аналитика, и почему такие потери возникают.

Дефекты

Самые очевидные потери – это дефекты. Дефекты есть в любой работе. В работе аналитика тоже регулярно возникают дефекты. Например, к дефектам можно отнести следующие ситуации:

• Когда какая-то информация осталась упущенной, недовыясненной.

• Когда какая-то информация осталась непонятной. Вообще, делать вещи понятными – это одна из главных ценностей бизнес-аналитика. Если аналитик сам все понял, но не может донести свои мысли до заказчика, команды разработки или смежных команд – это говорит о том, что в его работе есть дефекты. Неважно, по какой причине: он плохо разговаривает; не обладает достаточной информацией или использует неправильный язык. Например, китайцам не получится что-то рассказать на русском – для каждой аудитории надо выбирать правильный способ коммуникации.

• Также ошибки возникают, когда появляется неправильная информация: например, проводим исследование, но используем неверный источник, в итоге получаем “кривой фундамент”, на котором получается кривое здание.

Как можно минимизировать эти дефекты? Самые очевидные решения:

• Использование различных стандартов и шаблонов. Часто говорят, что шаблоны документов либо не нужны, либо избыточны. Но шаблоны документов устраняют один из основных источников дефектов – посмотрев на шаблон, аналитик может увидеть, какую информацию ему надо собрать, чтобы транслировать документ дальше. Шаблон задает для документа некую канву. Вы, наверное, слышали термин «паралич аналитика», когда не знаешь, с чего начать? Посмотрев на шаблон, можно хотя бы примерно понять, какая информация может потребоваться в документе. Сразу оговорюсь: шаблоны бывают избыточные. Карл Вигерс в своей книге «Разработка требований к программному обеспечению», писал: «Не заполняйте шаблон только потому, что там есть такой-то раздел. Сначала поймите, нужен этот раздел кому-то или нет. Если не нужен, не заполняйте».

• Definition of Done. Иногда аналитики допускают дефекты из-за того, что им не совсем понятно, что является конечным результатом их деятельности. Например, новый аналитик на проекте, исходя из своего предыдущего опыта, может считать, что команде для начала работы достаточно информации в таком-то объеме. А команда может оказаться с другим знанием, с другим бэкграундом – возможно, им будет требоваться либо больше, либо меньше информации. Об этом имеет смысл договариваться заранее;

• Про контроль качества очевидная вещь: старшие товарищи контролируют работу начинающих аналитиков. Понятно, что если начинающий аналитик пишет документацию и сразу ее отправляет без дополнительной проверки, вероятность возникновения дефектов более высокая.

Перепроизводство

Следующий вид потерь – перепроизводство.

Наверное, все себе представляют, как выглядит кризис перепроизводства в промышленном масштабе. А в работе аналитика перепроизводство – это, в первую очередь, производство ненужных артефактов:

• Особенно это актуально для Legacy-проектов, которые тянутся достаточно долго. Там накапливается огромное количество информации, и аналитик часто вынужден проводить ненужный анализ – выяснять какие-то специфические нюансы и потом их куда-то документировать.

• Кроме этого, на длительных проектах бывают устоявшиеся практики, из-за которых аналитик вынужден делать лишнюю работу. Например, оформлять лишние документы из-за того, что где-то было оговорено: «документация в комплекте поставки должна содержать такой-то перечень документов».
  Например, на одном из своих проектов я столкнулся с такой ситуацией – мы подготовили релиз и релизную документацию, но руководитель проекта сказал, что нужен еще один документ. Ранее я никогда не сталкивался с таким документом, поэтому у меня возник закономерный вопрос: «А зачем?».
  Со слов руководителя проекта, они всегда готовили этот документ, т.к. он указан в пакете релизной документации. Я на всякий случай решил уточнить, нужен ли он кому-нибудь, и если нужен, то для каких целе. Выяснилось, что этот документ не используется никем ни у нас в команде, ни на стороне заказчика. В результате ресурс аналитика тратился на подготовку артефакта, который никому не нужен. Это и есть перепроизводство.

Как устранять перепроизводство?

• Следование стандартам и шаблонам. Сразу оговорюсь: нужно регулярно делать ревизию правил, политик и стандартов, которые используются у вас в организации либо в работе аналитика. Потому что мир меняется, артефакты меняются, процессы меняются, ожидания заказчиков тоже. У двух клиентов могут быть разные ожидания: одному требуется один пакет документов, другому – другой, государству – третий. Адаптируйте ваши шаблоны под каждого заказчика и не заставляйте аналитика делать ненужную работу. И сам аналитик должен задать вопрос: «Насколько я ленив, чтобы делать лишние документы?»;

• Принятие решений. В какой-то момент имеет смысл четко сказать: «Я это делать не буду, потому что это бессмысленно или не требуется». И быть готовым это обосновать.

Ожидание (Непродуктивное)

Следующий вид потерь – непродуктивное ожидание.

Казалось бы, мы всегда чего-то ждем. Но когда мы говорим про бережливое производство, речь идет про так называемое непродуктивное ожидание, потому что ожидание бывает вполне себе продуктивным. Например, когда вы мясо поставили в духовку, оно должно там какое-то время постоять, чтобы приготовиться. Тут никуда не денешься, мы вынуждены ждать.

Когда мы говорим про непродуктивное ожидание – это то время, которое мы тратим, например, на:

• Поиск или предоставление информации;

• Ожидание работы смежных команд. Особенно если у вас интеграционный проект. Бывает так, что вы готовы свою фичу выкатить, а смежная команда еще нет. Вы вынуждены их ждать.

• Согласование и принятие решений. На одном из проектов был установлен пока абсолютный рекорд в моей практике : почти полгода документ крутился на согласовании у заказчика. Команда простаивала, регулярно спрашивала у нас о результатах, а мы ничего сделать не можем – решение не принято. Почему могут не приниматься решения? Например, из-за боязни ответственности.

Как можно это устранять:

• Оптимизация коммуникаций – сюда относится поиск правильных стейкхолдеров или эскалация. Правда, к сожалению, у аналитика, особенно, если это начинающий аналитик, не всегда есть возможность достучаться до самого верха и как-то ускорять процессы. Поэтому приходится ждать.

• В случае, когда мы вынуждены ждать смежную команду, мы можем распараллеливать работы: смотрим на работу смежных команд и заранее анализируем зависимости. Чем лучше вы представляете работу ваших смежников, тем больше у вас возможность сократить время ожидания. Вы заранее будете понимать, что команда не успевает. И тогда вы просто переключаетесь на какие-то другие задачи, чтобы не ждать.

• Планирование времени и улучшение управления – имеет смысл заранее скоординировать работу аналитиков в смежных командах, чтобы было общее видение, куда мы гребем. Потому что когда каждая команда делает свой кусок независимо, возникают проблемы и рассинхронизации.

Неиспользуемые возможности

Следующий вид потерь – неиспользуемые возможности.

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

Что здесь может быть?

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

• Это могут быть бесполезные административные задачи. Например, в так называемой in-house разработке, где на стороне заказчика есть свой отдел анализа и разработки, могут сказать: «У нас штат заполнен, поэтому мы не можем взять начинающих специалистов, у нас все задачи выполняет ведущий аналитик». И представьте: ведущий аналитик, который должен бегать относить документы на согласование. Его ресурс тратится неэффективно.

• Чрезмерный контроль или так называемый микроменеджмент, когда нужно в процессе работы составить кучу отчетов и направить руководителям разного уровня. Так происходит, потому что у руководства периодически возникает ощущение утраты контроля. Им кажется, что когда им предоставят отчет, они будут все контролировать. А осознание того, что специалист, вместо того, чтобы работать, вынужден писать эти отчеты, приходит не всегда. Потому что каждый руководитель видит только свой отчет, он не видит общей картины.
  В одной компании мы с коллегами столкнулись с тем, что нужно было подавать целую кучу отчетов: по спринту, по бэклогу, по статусу согласования, по реализованной интеграции, прогресс достижения цели. И мы там объявили «итальянскую забастовку»: раз в месяц целую неделю не брали рабочие задачи, а тупо заполняли все отчеты, которые требовались. Когда нас спросили, почему мы ничего не делаем, мы просто показали количество отчетов, которое нужно сформировать. Намек быстро поняли и количество отчетности нам сократили в разы.

Как устранять?

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

• Использование дополнительного вспомогательного персонала. Использование стажировок, джунов, обучения и так далее – очень эффективная тема. Даже просто обучение в рамках компании позволяет получить в свое распоряжение толковых ребят, готовых решать ваши небольшие задачи.

• Улучшение управления. Если брать практику, допустим, большой консалтинговой четверки, там есть определенные уровни сотрудников и определенные уровни задач, до которых квалифицированный сотрудник уже не опускается. Проще нанять более дешевый персонал для решения простых и небольших задач, в то время как высокоэффективный специалист будет сфокусирован именно на сложных задачах.
  Есть еще один интересный пример – на одном из моих проектов у нас был эксперт со стороны заказчика, человек очень квалифицированный, дедушка, которому хорошо за 70. Он работал в режиме примерно полгода через полгода. Казалось бы, ничего себе режим работы! Человек в принципе в офисе не появляется. И на мой вопрос: «А как его застать? Он когда-нибудь вообще с Карибских островов приезжает?» мне сказали, что он появляется, только когда компания сталкивается с ситуацией, которую не может решить никакой другой сотрудник. У него действительно работы в течение года максимум на полгода набиралась, но компании было выгодно иметь такого высококвалифицированного специалиста, потому что такие задачи мог решать только он. А все остальное время – пожалуйста, отдыхай. Это более правильное использование персонала и человеческих возможностей.

Транспортировка

Следующий вид потерь – потери, возникающие при транспортировке. Например, если мы что-то перевозим, это может сломаться.

В случае с бизнес-аналитиками потери при транспортировке возникают:

• При отправке информации от одного контрагента другому. Когда вы пишете письмо на много адресатов, и кто-то делает на него ответ, а потом кто-то другой из того же списка делает ответ, найти последнюю версию становится уже проблематично, потому что каждый начинает обсуждать свой кусочек. Возникает потеря информации, потому что начинается спам писем от разных людей.
  Я вообще считаю злом так называемые “корпоративные рассылки”, когда в письме на много адресатов просят: «Коллеги, просьба подтвердить свое участие в каком-то мероприятии». Если у вас компания на 15 тысяч человек, и на письмо идут ответы в режиме “Reply all”: «Я участвую», «Я участвую», «Я не участвую», переписка превращается в спам. Возникает потеря информации, потому что в потоке спама ее будет не найти.

• При переносе из одного документа в другой – когда мы начинаем терять какую-то информацию; неправильно интерпретировать либо добавлять ненужную информацию.
  В одном из проектов была забавная история. Во всех документах есть классический раздел «Термины и сокращения». Обычно аналитики задают вопрос: «А что туда писать?» Чтобы не сильно заморачиваться, они берут первый попавшийся документ, либо последний, который готовили, берут секцию и копируют в свой. После нескольких итераций копирования у нас на одном из проектов оказалось, что сам проект связан условно с банковским кредитованием, а терминология – из казначейства. Получается, что этот набор копипастов доехал уже до смежных подразделений, при этом ни одного нужного термина не содержал. Потеряли при транспортировке.

• Перемещение документов из одного места в другое. То же самое. Если у вас на проекте несколько файловых хранилищ, можете ли вы гарантировать, что один и тот же документ в папке у заказчика и у команды разработки – это одна и та же версия? При пересылке, копировании, при работе разных людей возникает накопление версий, которые, в том числе, при передаче уже начинают расходиться. Есть хорошие практики, как правильно нумеровать или именовать версии, чтобы хоть как-то отслеживать эти изменения.

Как снизить вероятность потерь при транспортировке?

• Использование общего информационного пространства. До последнего времени для этого чаще всего использовались Confluence либо SharePoint – в большинстве компаний они до сих пор так или иначе используются. Чаще всего создается под проект какая-то общая папка, где хранится вся информация. Понятно, если проект длится больше полугода, папок становится сильно больше: каждый создает свою папку, а внутри еще одну для внутреннего использования, и начинает возникать та же история;

• Адаптация процедур. Это опять же выстраивание либо регламентация процессов таким образом, чтобы не возникали ситуации с “массовым Reply аll”, с ответами на несуществующие вопросы и прочее. Мы всегда смотрим, как работают наши специалисты, потому что оптимизация процессов проходит через все бережливое производство.

Запасы

Следующий вид потерь – создание запасов.

Считается, что создание запасов на производстве в общем случае приводит к “закапыванию денег в землю”. Если на склад положили товар, вы платите за его хранение и таким образом несете потери как организация.

С точки зрения производства для устранения подобных потерь применяется вариант поставки just in time (точно в срок), когда процесс выстраивается таким образом, что запасы не создаются, а необходимые ресурсы поставляются непосредственно в нужный момент производства.

Как можно интерпретировать потери в виде создания запасов в работе аналитиков? Наши запасы – это наши артефакты, которые мы готовим.

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

• Усложняется поиск информации – чем больше у вас артефактов, тем сложнее их найти. В каждой компании так или иначе существуют различные надстройки над тем же Confluence или SharePoint, использование различных плагинов, правила присвоения меток и так далее. Этот инструментарий позволяет быстро найти нужную информацию, потому что копаться в различных документах в поисках нужной информации – это затраты времени. Особенно, если автор документа – не вы. Если вы не знакомы с документом на 500-600 страниц, нахождение нужной информации может вызвать вопросы.

Каким образом можно устранить этот вид потерь:

• Организация информации, организация общего информационного пространства, его выстраивание. Приходя на проект, проводите ревизию требуемой документации и сами выстраивайте структуру хранения организации информации – кто ведет, кто отвечает за согласование, кто ставит признаки финальной версии и так далее. Выстраивайте именно процесс управления информацией, хранения артефактов;

• Использование инструментов поиска и навигации. Для Confluence и SharePoint существуют различные плагины, надстройки, различные лейблы, метки – это все то, что помогает найти информацию;

• Регулярно удаляем ненужное. Здесь, правда, сразу вспоминается анекдот: «У нас давно хранится бумажный архив. Давайте мы его уже уничтожим, освободим место? – Да, можете уничтожить, только копии снимите». Это как раз к вопросу регулярного пересмотра. Старые версии имеет смысл либо в долгий архив убирать, либо проводить очистку и просто их удалять, оставляя последние актуальные.

Движения

Следующий вид потерь, причем в первую очередь потерь времени – это лишние движения.

Мне сразу вспоминается эпизод из фильма «Трое в лодке, не считая собаки», где дядюшка Поджер вешает картину: «Принеси свечу, принеси молоток, подержи лестницу…» в итоге картина не повешена.

О каких движениях в работе аналитика идет речь?

• Это, например, перемещение между офисами и зданиями. В “доковидную эпоху” аналитик, который работает в компании-разработчике софта на заказ, должен был регулярно ездить из своего офиса к заказчику на встречи. Просто представьте себе перемещение из с одного конца Москвы в другой – с Октябрьского Поля куда-нибудь на Ленинский проспект. Сколько это времени будет потрачено? Поэтому необходимо стараться группировать активности, организовывать, условно, день встреч с заказчиком – с утра ехать в офис к заказчику, где проводить серию встреч.
  В свое время, чтобы организовать одномоментно встречу заказчика из Германии и двух команд исполнителей из Киева и из Москвы, нам оказалось проще организовать трехдневный воркшоп в Турции, потому что не надо было решать визовые вопросы. Турция – безвизовая страна для всех этих трех стран. Иначе мы очень много времени потратили бы на ожидание, пока получим визы, купим билеты и прочее. Это было просто быстрее, и мы не тратили время на переключение.

• То же самое по поводу переключения между задачами и переходами между встречами или созвонами.
  Не ставьте ровные часовые слоты для встреч, потому что никто никогда вовремя не заканчивает – всегда остаются какие-то фоллоу-апы, которые надо “быстренько обсудить”. В режиме удаленки это не так наглядно видно, но когда встреча происходит в переговорке, это наиболее актуально. Вы сидите, обсуждаете последние штрихи, а в этот момент в дверь уже ломится следующая команда, потому что всем переговорок не хватает. Вас начинают выпихивать, и вы уже из коридора обещаете: «Да-да-да, мы все сделаем, вам пришлем». Все забывается сразу, потому что вас уже выпихивают. Дальше вы вскакиваете: «Елки, у меня уже следующая встреча!» и бежите на следующий этаж, в следующую переговорку. «Так, что я делал?» Мы теряем информацию, мы теряем время.

Как справляться с лишними движениями:

• Группируем активности. Вплоть до того, что выделяем день без встреч. У меня на одном из проектов каждая пятница называлась «no meeting day» – никаких встреч, никаких созвонов, дайте спокойно поработать хотя бы один день в неделю. Это было правило внутри компании. Понятно, что оно тоже нарушалось, но для большинства сотрудников эта была возможность спокойно поработать, суммировать активности, которые были.

• Организация пространства. Чтобы сократить количество встреч и перемещений разумно использовать какие-то общие пространства, общие локации. Например, в классическом Scrum рекомендуется сразу посадить всю команду вместе, чтобы им не приходилось постоянно мотаться по разным локациям.
  А у меня наоборот, до определенного момента значительное количество проектов были связаны именно с командировками за рубеж, и это количество перелетов просто выбивало из нормального режима. Например, мы с командой выезжали к заказчику для внедрения в Польше, а там по законодательству есть ограничения периода пребывания, нужно периодически выезжать из страны. Условно говоря, две недели сидит одна команда, потом на ее место приезжает другая, а первая уезжает. Так они полгода меняются, а через полгода вида полностью выбирается – полгода отдыхаешь, потом опять едешь.

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

Чрезмерная обработка

И последний вид потерь – чрезмерная обработка, она чаще всего возникает в работе у так называемых перфекционистов.

В работе аналитика чрезмерная обработка – это:

• Когда аналитик пытается выяснить какую-то ненужную информацию. Вернее, он-то считает, что эта информация нужна, но команде это может не потребоваться. Например, потому что команда хорошо знает предметную область, либо у нее есть какие-то уже готовые фреймворки, которые накладывают определенные ограничения. А аналитик, будучи перфекционистом, начинает это все раскапывать, тратит на это время. Это и есть та самая чрезмерная обработка.

• Еще к чрезмерной обработке относится анализ нереалистичных вариантов. Мне часто приходилось с этим сталкиваться, особенно раньше, лет 10 назад, когда задачи у системных аналитиков ставились по типу: «Проработай все возможные негативные сценарии». Коллеги, давайте смотреть правде в глаза: предусмотреть все негативные сценарии нереально. Я, конечно, понимаю, что тестировщик может придумать такие варианты негативных сценариев, которые мне, как здравомыслящему человеку, в голову не придут. Но когда аналитик при проектировании банкомата пытается описать сценарий, как должна себя вести система, если кто-то попытается запихнуть купюру в отверстие для банковской карты… Давайте исходить из предпосылки, что люди – здравомыслящие и их задача – не сломать систему, а все-таки использовать ее для решения своих бизнес-задач.
  Поэтому наша задача – найти те сценарии, которые помогают реализовать бизнес-кейс, и найти наиболее типовые ошибки. Все остальное имеет смысл реализовывать по мере продвижения, когда такие проблемы возникают.

Потери в виде чрезмерной обработки можно устранять следующими способами:

• Приоритизация, как один из инструментов, на чем фокусироваться – мы выстраиваем себе набор активностей, чтобы не тратить время на лишние действия.

• Командные ретроспективы как возможность получить обратную связь и своевременно понимать, когда уже хватит. Потому что в разных командах требуется разная степень проработки информации и документации.

Вопросы и ответы

Как вы завлекаете стажеров на бесплатную работу? Через вакансии или ходите по вузам?

И то, и другое, и третье. Но в России по поводу стажировок есть определенные ограничения с точки зрения законодательства – кого можно привлекать и на каких условиях. Т.е. стажировка – это не бесплатная работа, она оплачивается.

Мы приглашаем студентов в основном на различных конференциях, говорим: «Ребята, если хотите попробовать себя в Luxoft (или в EPAM), приходите – покажем, расскажем».

Обычно к нам на стажировку приходят студенты или специалисты других компаний, которые не дотягивают до требований по определенной квалификации. В этом случае мы им сразу озвучиваем на входе, что в такой-то период основной фронт задач у вас будет такой-то.

Например, сейчас к нам на стажировку вышла девушка-разработчик, причем на предыдущем месте работы она считалась старшим разработчиком, а в моей текущей команде, если сравнивать с ребятами, она объективно джун, максимум мидл. Мы ей сразу сказали, что на старшего она у нас в команде никак не тянет. И она это восприняла как инвестицию в свое будущее.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции «Анализ & Управление в ИТ-проектах».