Мой путь в 3д. Стажировка в геймдев компании
Этот пост будет скорее итогом того, что я смогла достигнуть за год изучения 3д. Ну и будут мои лучшие работы, можно скроллить картиночки:3. Мои предыдущие творения есть в старых постах на странице ( но они всратые и в большинстве своем сделаны по курсам из ютуб).
Напомню о себе:
Мне 26 лет, я логопед-дефектолог с 6летним стажем. Но ровно год назад решила резко сменить сферу деятельности ,"войти в айти," и стать 3д художником. В компах разбираюсь на уровне бабки, художественного образования нет, печатаю одной рукой. Короче все очень плохо, но я не унываю.
Сначала я делала стадики в программе blender : нужно засечь 40 минут и за это время успеть сделать предмет, который видишь в комнате. Покажу несколько самых удачных.
Но для 3д художника, который хочет работать в геймдев индустрии, просто уметь делать предметы недостаточно. Нужно уметь особым образом подготовить модельку к игре. Иначе игра будет очень много весить и ваш комп ее не потянет ( и не только потому что ваша видеокарта настолько древняя, что была сделана в каменном веке). Иногда, процесс такой подготовки бывает сложнее и дольше, чем само сотворение модельки.
И, чтобы научиться этому, я взяла платный курс с ментором. Оказалось, что в этом курсе вместо знакомого мне blender, используется совершенно новая для меня программа, Maya. Я узнала об этом уже после начала курса (невнимательно читала аннотацию). Пришлось изучать софт с 0 и смотреть лекции. Ментор нас всех игнорил по нескольку дней, а в конце недели требовал выполненное дз. К счастью, мой парень тоже 3д художник, который знаком с этой программой. По-сути он частично заменил ментора мне и нескольким людям с курса, отвечая на вопросы типо "ой я не туда тыкнул (а)", "оно само нажалось".
А еще меня заставили взять концепт танка, а я хотела смоделлить что-то милое). Ну, танк я взяла, но покрасила танк в розовый и добавила котика хе-хе). ПАТАМУШТА МАГУ. БУНД!
Мне было настолько сложно, что я сделала эту работу на чистом упрямстве.
После того как я прошла этот курс я сильно выгорела и была опустошена. Вдобавок мое зрение совсем испортилось и я заработала сходящееся косоглазие. В глазах все двоилось даже в очках и я не могла сфокусироваться на предметах целиком, что очень мешало не только жить (лестница мой враг), но и работать за компом.
В один из таких дней я и мой мч пошли в бар на тематическую встречу геймдев тусовки. Пока мой мч сидел на барной стойке и потягивал чай с видом английского аристократа, меня развезло после одного бокала сидра и я пошла знакомиться со всеми вокруг. Это выглядело примерно так.
Я увидела посреди бара компанию ребят, которые обсуждали преимущества использования ИИ в игровой индустрии. Сама концепция ИИ подрывает мне пукан и я ,естественно, не прошла мимо.
Я- я хочу, чтобы все компании использующие ИИ разорились, это неправильно!
Чел напротив- наша компания использует ИИ и у нас как раз есть бесплатная стажировка для начинающих 3д художников, ты приходи.
Я- *звуки переобувания* счастья, здоровья, процветания, денег побольше
Но все было не так просто. Меня взяли не на стажировку, а на подготовку к стажировке. Тот чел из бара оказался СЕО этой компании и он учил меня и ребят из потока полному пейплайну игровых моделей. Мы вместе созванивались в дискорде и делали полный пейплайн чашки (то есть чашку готовую к игре).
моя прелесть
После этого мы вместе делали пень (но не доделали). Этот чел был невероятно добр и внимателен ко всем. Мне очень хотелось попасть в эту компанию на стажировку. Но желающих было много, а места ограничены. Поэтому мне нужно было хорошее портфолио и мотивационное письмо. И я на несколько месяцев ушла с головой в работу.
Вот что получилось:
угадайте персонажа
Мое портфолио оценили и меня взяли!
Я была очень счастлива!
Всего нас было 9 человек. Мы всей группой собирались в офисе компании и делали одну и ту же модель. Не хочу деанонить компанию на весь Пикабу и поэтому не скажу что именно мы делали, если кому из тридешников надо напишу в лс, они офигенны).
Сама стажировка длилась 3 месяца, мы работали по 4 дня в неделю по 8 часов в день. У нас был специальный ментор, который тоже приходил в офис и объяснял нам весь пейплайн, помогая, если возникают проблемы.
Почему мы работали только 4 дня в неделю? Потому что вся компания работает только 4 дня в неделю. Потому что наш СЕО считает, что работать 5 дней в неделю-это бесчеловечно и он активно толкает эту идею в массы.
Но на меня четырехдневка не распространялась, мне приходилось ЕБАШИТЬ без выходных по 12 часов, потому что я не успевала и отставала от группы. А еще мое косоглазие начало прогрессировать и мне стало тяжело работать за компом.
Наш ментор со мной намучался(, но он навсегда останется в моем сердечке, его терпение просто железное. Я очень сильно подружилась с ребятами из группы. Но для меня не стало неожиданностью, что меня не взяли на работу после стажировки, единственную , кстати. Я все равно была благодарна всем за чудесно проведенное время. Я многому там научилась.
Тогда я уже не думала о работе или чем-то таком. Я думала только о том что я НЕ МОГУ НОРМАЛЬНО ВИДЕТЬ. Мне было страшно, что косоглазие прогрессирует с такой скоростью. Что я не смогу стать 3д художником, мне не хотелось жить и планировать свое будущее. И это одна из причин почему я не писала посты, как я обещала (ну и мне лень конечно было).
Тогда я решилась на операцию по коррекции зрения. Если интересно, расскажу об этом в отдельном посте. Мой мч взял кредит на 180к и мы специально вернулись в наш родной город.
И ТЕПЕРЬ Я ВИЖУ. Это офигенно. Ко мне вернулся стимул жить дальше. Сейчас я активно делаю портфолио. Хочу стать персонажником. Пока сделала вот такие суши) это 3д с 2д текстурами. А еще делаю прикольную девушку.
В общем мой путь сложен и тернист), но меня окружают замечательные люди. Хоть я и не добилась поставленных целей, но я счастлива и любовь и забота близких (особенно мч) помогают мне. Спасибо что дочитали).
Топ 10 ресурсов на русском языке, которые могут помочь в изучении Python
Вот список из 10 ресурсов на русском языке, которые могут помочь в изучении Python:
1. Python.org на русском языке – официальный сайт языка Python, который содержит множество документации, руководств, обучающих материалов и примеров.
2. 'A Byte of Python' на русском языке – это онлайн-учебник, который предназначен для начинающих программистов и помогает освоить основы языка Python.
3. Pythontutor.ru – это онлайн-платформа с интерактивными задачами и упражнениями, которые помогают закрепить теоретические знания.
4. Rus-linux.net – это портал, который содержит множество статей и обучающих материалов по Python.
5. Learnpython.ru – это онлайн-курс, который предоставляет пошаговый и практический подход к изучению языка Python.
6. Pythonworld.ru – это онлайн-учебник по Python, который содержит подробные описания синтаксиса языка, примеры и задачи для решения.
7. Pythonicway.com – это сайт, который содержит множество статей, видеоуроков и других материалов, которые помогают в изучении Python.
8. Coursera.org – на этой платформе можно найти большое количество курсов по Python от ведущих университетов и экспертов в области программирования.
9. Geekbrains.ru – это онлайн-платформа, которая содержит множество курсов по Python и другим языкам программирования.
10. Tproger.ru – это портал о технологиях и программировании, где можно найти множество материалов о Python и других языках программирования.
Большая подборка книг по программированию в телеграме!
Как я хотел облегчить работу в поликлинике
Многие, кто на меня подписан, знают, что я отработал некоторое время на скорой, и по настоящий день работаю в первичном звене (В поликлинике).
Я застал самые крутые волны ковида и вынес много опыта из этого шторма.
Самый главный- "Спасение утопающих - дело рук самих утопающих" - это я сейчас про врачей, хотя и про пациентов такое можно было сказать зачастую.
Но сейчас как раз о "Пятничном МОЁ". Захотелось ачивку и заодно рассказать вам о моем опыте, улучшения работы в поликлинике. А именно журнале вызовов - который у нас пишется по сей день в бумажном варианте.
Вызовов - переваливает за 300, и самая большая боль вначале рабочего дня: выбрать вызовы по своему району(ведь в журнале они в разном порядке), переписать в блокнотик, расставить маршрут.
И да, опытные врачи перепишут и пойдут по памяти, но согласитесь порой можно упустить или забыть маршрут, можно перепутать дома, такое часто встречается даже у тех, кто знает весь район по закоулочкам. А еще наверняка будет удобнее, если врач не будет тратить лишние 5 минут (во время ковида примерно 20, потому что вызовов очень дофига).
В один из прекрасных дней я сам заболеваю ковидом в легкой форме, и сижу дома, сидеть без дела не могу - поэтому придумываю, как бы облегчить работу - хитрый лис, который не хочет работать - скажите вы? -нет, просто реально даже за те деньги, что нам платили, работать было тяжело, а так можно было бы и большему количеству человек помочь.
Я сажу за компьютер и понимаю, что я не программист, хоть и навыками верстки я обладаю, но сделать что-то можно, вспоминаю все конструкторы, что есть: тильда, юкоз -понимаю, что не подходят, ищу информацию о "ноль-код платформах" - нет, я не рекламирую их, просто рассказываю, как замахнулся на MVP, а по факту мог получить готовый продукт..
Нахожу одну такую прекрасную платформу - название которой не скажу, чтобы не убили за рекламу. И начинаю что-то воять.
Цель которая передо мной стояла изначально:
Сбор адресов в удобном для всех приложении (изначальный вариант был плох, потому как врач так же должен был переписывать вызовы себе в телефон).
Построение маршрута
Пометки о вызовах (комментарии, к чему готовится)
Заключение, заметки для себя(что было на вызове, что в итоге решил и нужен ли больничный).
Что получилось в итоге:
Все что планировал
+возможность добавление вызовов регистратором из колл-центра, сразу с пк, которые стоят у них на месте.
+Возможность просмотра врачом истории своих вызовов и информации которую он заполнил на них для себя с любого пк
То есть в конце-концов, выстроилась прекрасная цепочка:
Колл-центр записывает вызов сразу в БД, адресуя его нужному врачу, который ходит по этой территории ->
вызов падает врачу в приложении\сайте (потому что загружать приложение в сторы мне не хватило времени, и я разочаровался в проекте)->
Врач сразу видит вызов и комментарий о нем, соответственно не тратит время на переписывание инфы + не тратит время на заход в колл-центр, а значит исключает личный контакт (во время ковида было очень кстати полезно).
К тому же врач вначале работы может сразу пойти на вызовы, а не заходить в поликлинику.
Если по пути работы врача вызовы добавляются, то они падают в "Колокольчик" - уведомления, либо через @mail (потому что я так и не разобрался, как настроить уведомления в браузероной версии), + встраиваются в очередь по маршруту.
Самое интересное, сейчас открыл проект- я умудрился наладить маршрут и очередность вызовов с помощью карт и какого-то скрипта написанного моим другом.
Проект все еще жив в моей-тестовой версии, но воспользоваться не могу, потому что сервис зарубежный и оплатить его не выходит.
Логика приложения для врача:
Тут уже и замашка на карту пациента - аналог создания своей МИС - Медицинская информационная система (нет этой цели у меня не было).
Но - удобная работа с вызовами, их количеством, вызов содержит в себе пациентов, которых либо добавляет регистратор колл центра, либо сам врач. Если врачу на вызове попались еще пациенты, на которых не вызывали, врач может самостоятельно их добавить. (так сказать попутные пациенты в квартире).
Ранжирование вызовов по их удаленности. (По тяжести не думал тогда делать, в основном тогда обслуживали- как удобнее).
Открытие карты в отдельном окне, открытие маршрута в гугл-картах, в основном это пеший маршрут, самый оптимальный по расстоянию. Сделал только возможность начала обхода с самой дальней точки района, так как делать работу принято было с конца.
Создание информации о пациенте - различные данные.
Логика приложения для регистратора:
Тут сложного ничего- залогинился (Логины и пароли выдавал бы админ-я).
Заходишь в журнал всех вызовов. Сверху справа есть кнопка добавления вызова, вписываешь инфу - пока говоришь по телефону и отсылаешь врачу.
Логика приложения для просмотра своих заметок и вызовов:
Тут еще проще - просто заходишь под логином, открываешь любой вызов и смотришь - где ты был, когда, как и что записал для себя. Легко и удобно, открыл это приложение и открыл свою МИС на работе Crtl+c Ctrl+v, и готово, сократил еще кучу времени на вбивание инфы. (Да во всех МИС есть шаблоны, но тут то еще быстрее находить пациента и объективно вписывать или жалобы).
По факту, когда врач приходил с вызова, у него все уже было в печатном виде -оставалось перенести это МИС.
Почему я не полез с этим куда-то дальше?
Потому что у видел, что в других городах это реализовано + реализовано вместе с той МИС на которой работают. Не хотел изобретать велосипед
Потому что не хватало знаний в разработке.
Потому что у МИС с которой мы работаем такое в планах уже 3 или 4 года, но я никак не вижу, или может оно есть, но наше руководство это не закупает.
Потому что к апи той МИС с которой мы работаем никто не дал бы доступ.
Почему я не стал оставлять это локально для себя и коллег?
Первый вопрос что меня мучал - защита данных, какой она будет, ведь это MVP и все на базе ноу-код платформы, а значит хз, что и как там защищено.
Знаю, что в других городах уже реализовано подобное и реализовано лучше и намного лучше, у знакомых врачей из определенных поликлиник в Москве даже выдают планшеты на работе с необходимым софтом, но у нас этого нет, мы привязаны к МИС с которой постоянно какие-то проблемы, возможно не с ней с самой, а с серверами на которых она располагается. Хотя оптимизация для "Астра-линукс" там ужасная, замечаем, как этаже МИС отлично работает на винде.
Но скажу честно мы тестировали данную "Разработку" - некоторое время, и действительно всем все зашло. Кроме старой школы.
Идей для разработки было много и улучшения, но куда ее предлагать я не знал, да и клинки или компании лучше закажут для себя что-то сами. Но если вам интересна еще одна моя "Разработка в ковид, с радостью расскажу".
Если что-то забыл напишу в комментах, а если вам интересно - спрашивайте
Дерзкая пятница
Как мы в компании поделили отдел разработки
Всем лучи добра! Меня зовут Николай Петров, но вы можете звать меня просто Вадим. Я работаю техническим писателем в одной компании компании. Мы разрабатываем систему электронного документооборота, а в статье я хочу поделиться тем, как мы один большой отдел поделили на несколько команд. Я не буду пересказывать очередную историю успешного успеха, а изложу процесс с моей субъективной точки зрения. Всё перевру, приправлю тупыми шутками и в таком духе.
Как у любой другой компании у нас была своя команда разработки, точнее две больших команды. Одна команда разрабатывала один продукт, другая — второй. Всё шло хорошо, приходили новые разработчики, команды постепенно разрастались, и к какому-то моменту стало понятно, что большие команды только усложняют процесс разработки и делают взаимодействие неудобным. Когда одни и те же ошибки исправляются по несколько раз разными людьми — это субоптимально. Также субоптимально, когда на утреннем стендапе 22 человека и пятиминутный разговор о проблемах выливается в получасовой сеанс психотерапии для одного-двух разработчиков. Так мы решили перейти от проектных команд к кросс-функциональным командам. Сейчас всё поясню.
TRIGGER WARNING: Прежде, чем я начну, прошу вас подготовиться к неожиданностям при прочтении статьи. Если текст кажется вам переполненным сарказмом, пожалуйста, не относитесь к нему слишком серьёзно. Если текст вас оскорбляет, не читайте его. Спасибо!
Сам понял, что сказал?
Сложное слово "кросс-функциональные" означает всего лишь, что все команды занимаются всем понемногу. Таким образом каждая команда выполняет задачи из разных проектов и владеет знанием обо всём продукте, а не только о его части. Почему так важно, чтобы каждый знал чуть-чуть обо всём, думаю понятно, но на всякий случай поясню:
- Каждый разработчик видит код разных проектов и немного понимает "как это устроено".
- Если кто-то заболел, ушёл в отпуск или уволился (и такое случается), кто-то другой подхватит его работу.
- Все вместе делают продукт, а не отдельную его часть.
Недолго думая, мы решили организовать встречу в лучших традициях демократии, где каждый может сам выбрать, что ему нравится больше всего. Встречу провели, конечно же, онлайн. Не все сейчас ходят в офис, да и офисы у нас в двух разных городах. Кто-то даже впервые показал своё истинное лицо. Не только аватарку, в смысле. Все дружно перешли по ссылке в Miro, где наш заботливый руководитель Денис заранее подготовил стикеры, на которых каждый записывал, чем он хочет заниматься.
Затем всем было предложено занять место за четырьмя столами. Столы были виртуальные, поэтому закусок не предполагалось, зато каждое место было подписано в духе "frontend-разработчик", "backend-разработчик", "бизнес-аналитик", "тестировщик", ой, простите, "QA-инженер", "технический писатель". Три обычных команды и одна типа сервисная — помогает другим и координирует работу. Всё потому, что бизнес-аналитиков у нас пока не так много да и технический писатель всего один (это я. Привет, мам!).
Где-то после этого была ещё встреча для каждой команды, где они долго и в лучших традициях древнегреческих мудрецов рассуждали о том, кто же должен быть "тимлидом", а кто должен ходить на общекомандные встречи и почему это могут быть разные люди.
После разделения каждая команда обладает всеми необходимыми атрибутами успешного коллектива:
- Дурацкие названия: Вжик, Горыныч, БЭМС (Боевые, Энергичные, Молодые, Симпатичные), Звёздочка
- Логотипы из картинок, найденных в интернете
- Командный дух, компетенции и опыт
Передел YouTrack
Команды есть, теперь надо как-то работать. Работаем мы в YouTrack, точнее с его помощью. Да-да, я знаю, что Agile, спринты, ежедневные стендапы и вот это всё от зарубежного диавола и вообще никому не надо. Если вы согласны, то пропускайте этот раздел и идите лесом дальше по статье.
Постараюсь кратко и на пальцах. Раньше у нас был один общий ютрек: все задачи в одной куче, которая распределялась нашим многозадачным руководителем Денисом. Теперь у нас по-прежнему один общий ютрек, но задачи распределяет маленький избранный народом тимлид.
Раньше каждые две недели мы планировали один общий спринт, на котором можно было просадить полтора часа времени, а теперь команды планируют спринты сами. А могут вообще отказаться от всего лукавого аджайла и планирования, если так проголосуют. Профит в том, что теперь на планирование тратится значительно меньше времени и нервов.
Мне так вообще в планировании не надо участвовать. А смысл? Всё равно каждое требование я потом должен буду задокументировать, вот я и документирую, а не планирую.
Раньше в ютреке было два проекта: платформа и web-клиент. Теперь у нас есть общие задачи производства, которые могут включать любой проект. Были задачи типа WebC и задачи DV5, а стали просто TSK (может быть как WebC, так и DV5, так и вообще что угодно). Раньше ошибки записывались как обычная задача, а теперь в специальную задачу типа ERR. Видишь заголовок и сразу понимаешь, где собака зарыта.
У каждой такой задачи есть поле "команда", в котором указаны ответственные. Приходишь такой в требование, смотришь, кто ответственный, сразу знаешь, на кого наехать, чтобы узнать инфу.
А ещё у меня появился свой тип TSK-задачи — задание на документацию. У моих особых задач нет ревью и тестирования, они сначала открыты, потом в работе, потом закрыты. Всё.
Расскажи ещё, как у вас круто получилось
Работать правда стало намного увлекательнее. Появился чёткий ритм. Утром стендап (5-15 минут) и обсуждение командных проблем, потом избранные приходят на синхронизацию и рассказывают проблемы на общекомандной встрече (обычно минут 5-7). Каждые две недели ретроспектива (как поработали) и планирование (что будет делать дальше) и общекомандное демо (показать всем, как работает сделанное за 2 недели). И это не полуторачасовые встречи как раньше, а реально динамичные и полезные события. Мне особенно нравится демо, потому что теперь мне не надо сидеть и втыкать в требования часами, включая воображалку "а что же тут подразумевалось? а как же это задокументировать". Команды всё покажут и объяснят сами!
Ладно, кого я обманываю, всё равно мне приходится втыкать в требования часами, потому что я тупой.
Команды стали максимально автономными и независимыми. Они не ограничены ничем кроме достижения поставленной цели — выпуск продукта. В своих маленьких коллективах коллеги разработали свои методики автоматизации, особенные алгоритмы взаимодействия и т.д. Например, в Звёздочке разработали систему ачивок за количество закрытых требований в спринте. Если они закроют XX, YY, NN требований, то получат одну, вторую и третью звёздочку соответственно. Причём именно полностью закроют, включая документацию. На вопрос "а что если я не успею задокументировать их требование, и оно не будет закрыто", мне ответили, что могут вежливо попросить меня поторопиться. Что даёт мне некоторую власть над целой командой. Власть опьяняет.
В любом случае получилось классно! Демократичность, открытость и самостоятельность — вот как бы я охарактеризовал нынешний процесс.
Гонишь, не может всё быть так гладко
Может и гоню, но совсем чуть-чуть. Вот настолько:
Дело в том, что у нас в компании налажено ревью кода. Это когда один разработчик приходит к другому и говорит: "смотри, какой классный код я сделал!", а второй ему отвечает: "почитай чистую архитектуру Мартина, тогда поговорим".
Короче, у нас было несколько вариантов организации ревью, и мы не знали, какой из них выбрать:
1. Итеративное ревью.
--- Взяли задачу. Ответвились, сделали доработки по фронту и по бэку.
--- Перед передачей на приёмку бизнес-аналитику делаем ревью фичи целиком. Заодно подмержили develop.
(Есть мнение, что разработка в отдельных ветках — это прошлый век. Вот и пусть будет.)
--- Сделали хорошо, довели ревью до одобрения и передали на приёмку.
--- Если нужна доработка, повторяем предыдущие пункты.
--- Если доработка не требуется, передаём на тестирование.
--- Проводим багфикс.
--- Когда готовы, делаем ревью изменений по багфиксу в целом, обратный мерж и вливаем в develop.
Вот видите, всё просто!
В таком случае ревью будет чуть масштабнее и сложнее, но делать его нужно будет реже. Одна команда сможет ревьюить другую, будет коллективное владение кодом, дети в Африке не будут голодать и будет рай на Земле. Только не спрашивайте, как это работает, моё дело — рассказать.
2. Ревью через merge-реквесты. Работает вот так:
--- Один разработчик написал код и перевёл его на ревью.
--- Автоматически создаётся отдельная ветка и назначается ревьюер.
--- Ревьюер должен обладать теми же знаниями, что и автор кода. Ну, типа клиентский разработчик не может ревьюить серверного, сишарпер не может ревьюить джаваскриптера и т.д.
--- В этой ветке коллеги обсуждают чистоту архитектуры, а затем ветка мержится в девелоп, и все довольны.
--- Можно организовать сразу через гитлаб, минуя upsourсe, в котором всё делалось до разделения.
Знаете, какой вариант мы выбрали? Никакой!
Код-ревью делается по каждой задаче или ошибке по возможности внутри команды. Если это не возможно, то кросс-командно. Ревью создаётся по коммитам для задачи или ошибки в любой ветке.
Неудобные вопросы после разделения на команды
- Как будет проходить регресс?
--- Ожидание: Все задачи регресса будут равномерно распределяться по командам. Или одна команда делает большую часть, а другие помогают.
--- Реальность: После разделения мы ещё не дошли до регресса, поэтому практического подтверждения нет.
- Кто будет брать случайно найденные ошибки из общего чата?
--- Ожидание: Под индивидуальную ответственность. Нашли, записали, а дальше задачу в работу берёт та команда, которой задача больше нравится. Или в зависимости от загруженности.
--- Реальность: Всё так и работает. До сих пор не было проблем.
- Как будут распределяться дежурства по ТП?
--- Ожидание: Очень просто. Дежурят не команды, а дежурят люди. Если загруженность по ТП большая, можно подключать людей из других команд. Если загруженность небольшая, то дежурные могут совмещать дежурство с повседневными задачами.
--- Реальность: В целом всё так. В крайнем случае особенно большой загруженности можно забить на SLA и решать задачи в комфортном темпе. Но это неправильно и мы так не делаем, конечно же. Честно-честно.
- И как полёт сейчас, спустя месяцы?
--- Ожидание: Никто не ожидал, что команды будут статичными.
--- Реальность: Кто-то ушёл, кто-то пришёл, кто-то перевёлся из соседнего отдела. Бизнес-аналитиков набралось на все команды по одному, как и задумывалось. Но есть некоторый недостаток разработчиков.
Выводы
Короче, разделение на команды — это прикольно и совсем безболезненно. Как ни странно, но после разделения мы узнали друг о друге больше, чем до этого. У каждого даже появилась своя карточка с основной информацией о человеке. Типа любимые занятия, почему он тут и к чему стремится. Очень интересно, обожаю такое.
Новичкам теперь легче влиться в небольшую команду, понять процессы и начать работать. Короче, недостаток людей — плохо, избыток — тоже плохо. Если у вас огромная команда и становится сложно управлять процессами, подумайте о разделении, это реально работает.
А если вам нравится стиль статьи, подписывайтесь на мой телеграм. Если стиль не нравился, всё равно подписывайтесь, вдруг телеграм понравится.