Как пасти котов в условиях российского IT?
В идеальном мире не нужно никем управлять: все работают сами. Но мы живем не в нем, да и айтишников часто сравнивают с котами — умными, сытыми и независимыми. Если их не контролировать, все идет наперекосяк. В статье расскажем о том, как мы в Пиробайте взаимодействуем с командой на каждом этапе, чтобы все шло как по маслу. А в конце вас ждет бонус :)
Вначале упомянем про наш любимый Scrum, а после поделимся тем:
— как формируем команду под каждый этап разработки;
— как распределяем задачи между сотрудниками;
— в чем сложности управления котами и как мы их решаем;
— как повышаем качество своей работы;
— что делаем для того, чтобы проект успел запуститься в срок.
Что такое гибкие методы и зачем они нужны
Современная разработка — это сложная командная работа. Чтобы она шла эффективнее, используются гибкие методологии, например, Agile.
Короче говоря, Agile — это не про отчетность, документооборот и четкий план, а про постоянное общение с клиентом и готовность оперативно реагировать на изменения в ходе проекта.
Пример жесткой методологии — водопадная (каскадная) модель. По ней вся работа строится последовательно от этапа к этапу. Пока предыдущий не завершен, следующий начинать нельзя. Подходит для консервативных бюрократических структур.
К отдельным Agile-подходам относятся Scrum и Kanban
Канбан — это методика управления проектами, при которой этапы разработки визуализируются на виртуальной доске. Наглядность нужна, чтобы рабочие процессы протекали эффективнее. Команда понимает на каком этапе находится та или иная задача.
Скрам — это методика управления проектами, которая помогает командам структурировать работу. Под каждый проект собирается команда специалистов с распределенными ролями, работающая на общий результат. Разработка ведется спринтами — короткими периодами в 1, 2 или 3 недели. По окончанию каждого периода команда получает обратную связь о работе, а заказчик может протестировать самые важные с точки зрения его бизнеса функции.
Как мы собираем команду под проект
Любой проект — результат работы множества специалистов: аналитиков, дизайнеров, разработчиков и тестировщиков.
За всеми ними стоит менеджер, который контролирует сроки и качество на каждом этапе.
Аналитика
Первым, кого мы задействуем в работе — это аналитик. Ищем сотрудника, у которого уже был опыт проведения анализа в смежных областях. За качество этого этапа отвечает вся команда: аналитик вместе с руководителем отдела и менеджером согласовывает все основные моменты, касающиеся продукта.
Зачем нужен этот этап? Основная цель наших заказчиков — получить полезный продукт, приносящий прибыль. Но есть риск, что проект, в который были вложены деньги и силы, окажется невостребованным на рынке и понесет убытки. Предпроектная аналитика помогает свести этот риск до минимума.
Вот здесь мы подробно рассказывали о том, как аналитика помогает сделать проект успешным.
Проектирование
Следующий этап. В нем принимают участие арт-директор, менеджер и аналитик. На нем мы создаем черно-белый прототип — интерактивную модель будущего сайта с упрощенной графической частью.
На модели видно, как расположены блоки, по ним можно кликать, открывать попапы и исследовать меню. Это помогает визуально понять структуру сайта, оценить ее юзабилити, проверить как пользователь будет перемещаться и доходить до своей конечной цели.
Прототип делается черно-белым специально, чтобы не отвлекать заказчика на картинки и вау-эффекты. Их мы обсудим потом, а на этом этапе важно проработать максимально удобный интерфейс.
Дизайн
После того, как прототип отрисован, мы переходим к дизайну. В создании концепции участвует дизайнер, арт-директор и менеджер. Дизайнер задает стиль, оформляет страницы, отрисовывает кнопки и создает анимации.
Есть 2 варианта реализации дизайна — уникальный и шаблонный. Наши проекты мы создаем только уникальными. Такие сайты любят поисковики, они запоминаются пользователю и не теряются в массе подобных. Подробно о том, какого подхода мы придерживаемся при разработке дизайна, можно почитать здесь.
Как только дизайн страниц отрисован, стартуют сразу 2 этапа:
- Пишется ТЗ (если это сложный сервис с интеграциями) или бэклог (если проект не слишком крупный). Их пишет аналитик. Backlog — эта таблица со списком рабочих задач, которые расположены в порядке важности. Задачи в таблице оцениваются по приоритетам, их обозначают цифрами. Между цифрами остаются промежутки, в которые можно добавлять новые задачи, легко меняя приоритетность. Благодаря этому работа становится предсказуемой, планировать спринты становится проще. Про организацию спринтов рассказывали здесь;
- Верстка. Этим занимаются фронтенд-разработчики, в дальнейшем они же занимаются и разработкой. На этой стадии объединяются графика и код. Мы адаптируем макет так, чтобы дизайн смотрелся одинаково красиво и на компьютере, и на смартфоне.
Программирование
На этапе разработки происходит особая магия, оживляющая макеты. А волшебниками, которые заставляют сайт работать, выступают Frontend и Backend разработчики.
Backend — это серверная часть сайта. Разработчик отвечает за хранение информации, обработку, аутентификацию пользователей, интеграцию со сторонними системами: картами, платежными системами, социальными сетями, 1С и CRM. То есть за то, что скрыто от глаз пользователя. Это невидимая, но очень важная работа, без которой сайт останется просто красивой картинкой.
Frontend делает сайт таким, каким его видит пользователь. Настройка ссылок, анимации при наведении курсора, эффекты при взаимодействии с отдельными элементами интерфейса — все это результат их работы.
Сколько программистов участвуют в разработке?
Зависит от самого проекта и его объема. Если это небольшой стартап, достаточно одной команды:
— 2 фронтенда (разработчик + старший разработчик);
— 2 бэкенда (разработчик + старший разработчик);
— 1 тестировщик;
— аналитик и дизайнер (во время разработки они тоже не отходят от задач)
Для MVP это оптимальное количество, добавлять больше разработчиков в команду не стоит, потому что производительность будет увеличена не на +1, а на +0,5. Времени на стыкование задач и тестирование будет уходить больше. А когда команда состоит из 4-6 человек, производительность сохраняется.
Но опять же — все зависит от проекта. Бывает, что количество разработчиков может увеличиться до 10-15. Если проект крупный, то собираем 2-3 команды.
Тестирование
Как и менеджеры, тестировщики (QA) тоже сопровождают проект на всех стадиях:
— На этапе аналитики. Здесь они вычитывают ТЗ. Зачем? Чтобы проверить соответствие требований заказчика и видения разработчика. Чем раньше найдется баг, тем дешевле он обойдется для заказчика — изменить пару строк в ТЗ проще, чем исправлять код.
— На этапе проектирования и дизайна. Здесь ребята оценивают UI/UX интерфейса и пользовательский путь. Проверяют, чтобы расположение блоков совпадало на всех экранах;
— На этапе тестирования кода и верстки. Тут QA-специалисты проверяют работоспособность кода. Цель этого этапа — выявить ошибки в работе программы и исправить их до запуска продукта. Речь идет как о незначительных, так и о критических багах, которые могут не только помешать использованию сервиса, но и сломать его.
Это не значит, что если тестировщик не протестирует проект, клиент получит некачественный продукт. Дело в том, что программа в ответ на самые обычные действия пользователя может выдать непредсказуемый результат.
Разработчик, скорее всего, не заметит мелких дефектов, зато конечному пользователю они могут отравить жизнь. Поэтому QA проверяет все возможные и невозможные сценарии поведения пользователей, чтобы убедиться, что программа продолжит работать.
На один проект выделяется 2 тестировщика. Старший тестировщик контролирует работу первого.
Как распределяются задачи между сотрудниками
Рассмотрим на примере дизайнеров.
Если на проекте нужно применить lottie-анимации, мы отдаем задачу сотруднику, который владеет этой технологией лучше всего. То же самое с остальными задачами.
У всех дизайнеров есть пул работ, которые они должны уметь выполнять:
— работать по дизайн-системе, созданной на основе атомарного дизайна;
— разрабатывать дизайн-концепции;
— делать адаптивный дизайн;
— уметь анимировать и монтировать;
— работать с Photoshop, Figma, After Effects, Spline, Tilda, Webflow;
— разбираться не только UI/UX, но и в Motion Design, 3D-сценах, AR/VR.
Дополнительно они должны читать профильную литературу, смотреть вебинары и разрабатывать собственные проекты.
При этом у каждого сотрудника есть индивидуальные навыки: кто-то лучше анимирует, кто-то круче рисует от руки. Кому-то легко даются 3D-анимации, а кому-то AR/VR. Тогда есть смысл передать задачу сотруднику, который сделает ее лучше.
Что касается разработчиков, то для них ставятся связанные задачи.
Распределяются они по опыту работы: один хорош в интеграции, другой «съел собаку» на авторизации. Плюс никто не отменяет опыт, который тоже помогает грамотно распределить задачи между программистами.
В чем проблемы управления айтишниками и что с этим делать?
Как мы уже сказали, за командой стоит менеджер. Если попросить его вспомнить о сложностях, связанных с управлением, он кинет ехидную ухмылку — станет понятно, что их полно.
В основном проблемы связаны с когнитивными искажениями, которые есть у всех. Но среди исполнителей-айтишников особенно распространены такие:
— Критика результата воспринимается как личное оскорбление. Это искажение часто встречается у творческих, сонных и голодных сотрудников;
— Генерализация частных случаев. Это когда человек расширяет поставленную задачу и при этом не понимает, что ее можно сделать проще и быстрее;
— Проклятие знания. Это когда более информированный человек не может рассмотреть проблему с точки зрения человека, который знает меньше;
— Слепое пятно в отношении когнитивных искажений. Человек, который в курсе, что они существуют, отрицает, что они влияют на его поведение. А последствия списывает на обстоятельства и на глупость окружающих.
Наши Project-менеджеры знают, как работают когнитивные искажения, а значит могут регулировать их.
Например, решая сложную задачу, сотруднику может показаться, что она невыполнима. Чуть покопавшись в одной из них, тот говорит — «это невозможно». Но это не значит, что ее нельзя решить. В таких случаях менеджеру нужно уточнить у исполнителя, какие ресурсы ему нужны, чтобы выполнить задачу в срок.
А если сотрудник оскорбляется на критику, которая относится не к нему, а к его работе, менеджер поступает так:
- Вспоминает положительные моменты и хвалит исполнителя. Это важный момент. Мы стараемся выдавать много положительной обратной связи;
- Объясняет в чем его ошибка. Возможно, подчиненный не знает, как ее исправить и поэтому сопротивляется;
- Настаивает на переделке плохого.
Проклятие знания, например, устраняется не менеджером, а самодрессировкой. Котику нужно отлавливать свое нелогичное поведение и наступать себе на хвост.
Как мы понимаем, сколько ресурсов выделять на проект?
Мы его оцениваем.
Делается это в несколько этапов:
1) Первоначальная оценка
Есть 2 способа это делать:
— опереться на свою картину мира в прошлом (свой опыт);
— подключать здравый смысл и иногда интуицию.
Мы оцениваем проект, основываясь на свой опыт и здравый смысл. Если мы не разрабатывали точно такой проект, но делали что-то подобное, то примерно представляем, сколько времени на него уйдет.
Если задача новая, мы оцениваем проект предварительно. После этого проводится переоценка.
2) Переоценка
Делается после каждого этапа:
- Сделали предпроектную аналитику — переоценили;
- Сделали прототип — переоценили;
- Сделали дизайн — переоценили.
Зачем это нужно?
После того, как завершается очередной этап, уточняются детали следующего этапа. Вырисовывается уточненная оценка. Например, нужен сервис по бронированию квартир. Что в нем должно быть — мы примерно понимаем, потому что работали с такой задачей. Но какие-то детали будут известны после предпроектной аналитики, дополнительные детали — после прототипирования и так далее.
Если после переоценки добавляется функционал, стоимость разработки возрастает. И наоборот — если убирается ненужный, то уменьшается.
Саму разработку мы оцениваем по другому методу — Planning Poker
Зачем она нужна и как ей пользоваться?
Перед тем, как начать спринт, команда собирается в переговорке, предварительно вычитав бэклог или ТЗ. Обсуждает насущные задачи, относящиеся к будущему спринту. Всем все понятно, вопросов нет. Начинается планирование. Менеджер раздает колоду карт каждому члену команды, кладет рубашкой вверх, переворачивает песочные часы. Ребята вскрывают карты.
Что дальше?
А дальше результат. У одного 4, у другого — 5. Все окей — планирование прошло успешно, идем дальше. Озвучена новая задача, время пошло. Карты вскрываются: у кого-то цифра 8, у кого-то — 3. Упс... Почему такая разница?
Обсудили. Выяснилось, что один забыл о важных нюансах, другой хотел изобрести велосипед.
Планироваться нам помогают не только игры в покер, но и практика декомпозирования. Мы разбиваем большие задачи на маленькие, чтобы их было проще оценить.
Как это происходит на практике?
Берется готовый проект, разбивается на составляющие — чтобы человек понял суть задач и мог дать точную оценку.
Что делать, если команда не укладывается в срок?
Редко, но бывает, что сотрудник недооценил сложность задачи — для заказчика в этом нет ничего страшного. Потому что при составлении карты проекта закладывается буфер — подстраховка на случай форс-мажоров. Обычно это день или два.
Но что делать, если команда сожгла все буферы или не успевает запустить проект в релиз?
Тогда смотреть по ситуации. Возможно, эту задачу делать не надо. Или надо, но не сейчас, а в следующий спринт. Если надо сейчас, то нужно пробовать оптимизировать время на других задачах, чтобы успеть в дедлайн. Но в любом случае нужно ставить заказчика в известность.
Что такое ретроспектива и как она помогает улучшить качество работы команды
После каждого спринта менеджер собирает команду, чтобы обсудить, что было сделано хорошо, а что можно было улучшить.
Ретроспектива нужна, чтобы извлечь полезный опыт, который поможет работать над следующими проектами лучше. То есть мы оглядываемся в прошлое, чтобы стать лучше в будущем. На ретроспективе можно узнать впечатления команды от работы и собрать идеи по улучшению процессов.
Вот так выглядят итоги ретроспективы. Команда обсуждает спринт, фиксирует результаты:
Теперь вы знаете, как строится работа по этапам в веб-студии и как мы взаимодействуем с командой на них. Если хотите копнуть глубже и узнать, как развивается IT-продукт, переходите в прошлую статью. Там мы рассказали как превращаем велосипед в космический лайнер.
А теперь делимся с вами обещанным бонусом — держите инструкции о том, как правильно декомпозировать задачи и контролировать сроки. Пригодится руководителям веб-студий и менеджерам проектов.
Если у вас есть задача разработать сайт или мобильное приложение, то напишите в Телеграм, мы это обсудим: https://t.me/sashadzen
Заказать разработку сайта, веб-сервиса или мобильного приложения на нашем сайте: https://vk.cc/cuglQZ
Партнерская программа, где мы платим от 10 000 до 200 000 рублей за контакты тех, кому нужен дизайн или разработка: https://vk.cc/cuglXT
Телеграм-канал Саши Комбарова про управление агентством, проектами, людьми: https://t.me/sasha_kombarov
Телеграм-бот, который бесплатно выдает чек-листы, памятки и регламенты по управлению, маркетингу, аналитике, дизайну и разработке: https://t.me/regulations_pyro_bot
"айтишников часто сравнивают с котами"
Ни разу не слышал, чтоб их так называли. Дальше не читал, ибо невозможно осилить такую простыню.
Теперь слышали) А еще есть одна интересная книжка
Потому что у них лапки!
нужно подготовить отдельную статью - "как кормить крыс"
Эту картинку надо было на главную в статью)
Дедлайн особенно харизматичен.
Прочитал как работаете.
Посмотрел на ваш ужасный офис напичканый людьми и где солнечный свет закрыт наглухо шторами.
Спасибо господи что я слишком тупой для программизма (ваще не асиляю математику но могу с горем пополам чтото накидать для микроконтроллера) и пошел в сисадмины))
Солнечный свет очень мешает, отражается с мониторах, бликует. Так же у окна сижу с постоянно закрытыми жалюзи. Но офис действительно какая-то шляпа, шторы вместо жалюзи - вы там в театре?
Показатель отношения к сотрудникам, которые по 9 часов пишут что-то - это столы и они у вас ужаснейшие. Из выбирал не тот, кто будет за ними работать, а какая-нибудь девочка менеджер «ну они красивые, подходят по стилю»? На фото у первого же чувака, при том что клавиатура отодвинута максимально, руки просто свисают, очень удобно да? Кресла все разные и все с базара бу мебели видимо.
Это аутсорс так, что скорее всего вы слишком умны для аутсорс и пошли в сисадмины.
Комментарий недоступен
:)
Фотография из статьи очень интересна - обратите внимание - центральное положение, под рукой, занимает на столе телефон, клавиатура отодвинута далеко назад (чтобы не мешалась телефону) и даже надвинута на подставку монитора, то есть работать на ней невозможно. Мышкой тоже особо не поработаешь так как ее провод натянут отодвинутой клавиатурой. Но для фотографии парень отложил телефон и положил одну руку на телефон, а другой поддерживает клавиатуру, чтобы она не слишком палево стояла криво на столе.
Какая милая выдумка. Разработчики на фотографии не подозревали, что они под объективом)
Тут еще на фотографии у некоторых додиков уже есть гиперлордоз шейного отдела позвоночника. В будущем у них будут проблемы с головными болями, бессонницей, давлением и т.п. И когда их родственники, будут навешать их в больничке, надеюсь эти будут рассказывать про свою работу по скраму на дядюшку Джо, который привел их к такой жизни...
Огненная статья.. Еще никто так весело и задорно не описывал водопад, называя его скрамом, как ребятишки из пиробайта
Будем благодарны, если вы пришлете кусочек текста, в котором мы старательно называем водопад скрамом)
Какие преимущества дает клиенту Scrum?
— Быстрый запуск проекта с самыми важными функциями и минимальным бюджетом;
— Контроль над ходом работ и бюджетом.
Очень спорное утверждение. По моему главное отличие скрама от классической проектной разработке это в разы больше болтологии, сама технология подразумевает скрам собрания с участием всей команды.
В проекте прожект может обсудить задачу или проблему с конкретным разрабом, в скраме надо собирать всю банду, щоб все были в курсе. Как тут будет запуск быстрее?
А минимальный бюджет в скраме откуда? Заказчик платит за часы, разрабы в проекте подключаются по этапно, клиент платит за реальную работу, а в скрам сразу все щоб быть в курсе, и клиент платить всей банде. Или вы заставляете бесплатно разрабам сидеть в скраме пока их часть работы не будет нужна?
Главное отличие Scrum - это жесточайший контроль
Если убрать все модные слова и оставить только конкретные действия то получиться при мерно следующее:
1. Все участвуют в обсуждении недельных задач
2. Каждый берет конкретную задача
3. Каждый рассказывает с какими трудностями столкнулся
4. Коллективная ответственность (!) при разном уровне оплаты
5. И вишенка, Scrum Master - это лидер-слуга, который по Scrum Guide, внимание, не отвечает за результат(!) https://scrumguides.ru/scrum-guide.html#scrum-definition
Так что Scrum это прекрасный инструмент для управления слабыми командами, где нет доверия:)))
Есть ещё отличный термин в Scrum Guide - бережливое мышление. Очень запутано. Единственный критерий оценки - это результат. Всё остальное лишь способ отвлечь от оценки конкретных результатов
Так вот чем вы занимаетесь на этих ваших планерках - в карты играете (!)
Зря время не теряем :))
Вообще не логично, в итоге получится что у вас работает самый опытный всегда больше всех. Я думаю у вас на местах таки развивают кадры и дают остальным задачи.
Planning PokerОпять конкурсы с тамадой, неужели сложно в случае сомнений по срокам спросить тимлида/другого разработчика?
Ну и опять эти ваши ретроспективы без нормальных результатов. Почему нельзя все проработать в обычном рабочем режиме, а устраивать встречу на которой опять напишут - ведите дела во всех наших инструментах, а то нехорошо, вместо того чтобы просто поговорить с людьми и рассудить по проблемам с ними. Видно бесполезность этих встреч по картинке в идеях и предложениях.
Ретроспективы помогают подвести итоги уже после проведенной работы, когда все участники процесса - и руководители, и разработчики - могут высказаться о том, что на проекте делалось хорошо, что - могло быть лучше. Это помогает в работе с другими проектами.
Комментарий недоступен
Было интересно почитать, спасибо за контент!
Спасибо, Константин 🤝 Рады, что вам нравится
столы в офисе не регулируются по высоте - этим уже все сказано. заботы о здоровье подчиненных - ноль. и кондей еще дует сбоку на тех кто там сидит по ряду - просто идеальное решение.
кондей на стене говорит нам о том что это не настоящий нормальный офис в нормальном БЦ а в так называемом "БЦ" - переделанном из какого то старого здания - без особого соблюдения стандартов. Стены покрасили,ламинат положили, кондей повесили - ну чем вам не офис.
шторы - еще один показатель. в нормальных офисах есть жалюзи. Шторы ктото стирает? Или он так и висят и пыль на себе собирают?
Зачем на людей, которые отрабатывают больничный в свои выходные еще и кондей подстраивать и шторы стирать? лишнее все это
Зато регулируются стулья! :)
— Работающий продукт важнее документации;
Вот когда заказной продукт вы как говорите клиентам что документации не будет? Или будет но потом?
Вот к примеру у вас заказ на приложение. Вы чего говорите клиентам давайте сначала мы сделаем за вас счет MVP? Посмотрим работает ли он, а потом сделаем ТЗ и проектную документацию?
Насколько я в курсе, обычно все предлагают наоборот, сначала предпроектное обследование, потом проект, потом тз, потом MVP, потом продукт.
Тогда вроде как получается документация важнее работающего продукта?
Это один из пунктов манифеста agile, речь там шла о технической документации, понятно что клиенту надо давать документацию для использования продукта.
Документация есть и будет. Речь о том, что если мы в бэклоге прописали, как работает функция, но затем поняли, что она должна работать иначе, то мы не будем слепо следовать документации.
Не жалеете вы Олега:)
В любой непонятной ситуации за риском следит Олег)
Отличный материал, благодарю! И отдельная благодарность за ссылки на другие ваши публикации, часть читал, но некоторых ещё видел 👍🏻
Вопрос: сколько человек участвует в подготовке таких материалов у вас?
Спасибо, Вадим 🤝 Рады быть полезными!
Зависит от самого материала. Если статья об управлении, то участие принимают не только копирайтеры, но и менеджеры. Чем больше менеджеров будет опрошено - тем лучше и обширнее получится материал. Если статья о разработке - разработчики, о дизайне - дизайнеры. Если разворачиваем кейсы, то участие принимают вообще все, кто имел отношение к проекту.
Подробнее об этом рассказывал наш исполнительный директор на Хабрасеминаре, эти выжимки можете почитать здесь - https://vc.ru/marketing/754603-kommentarii-udalyaem-heyterov-blokiruem-o-chem-govorili-na-habraseminare-v-2023-godu
тот случай, когда название заинтересовало и захотелось прочитать статью)
Мы старались :)
Комментарий недоступен
Комментарий недоступен
Комментарий удален модератором
Рыночек порешает кто из нас прав. :)
Комментарий недоступен
Коллеги, скажите честно - кому нравятся лонгриды?
Мне, например, если там не водичка, а "мясо". Хорошо раскрытый материал идёт в закрома. Короткое - ну, максимум, оставлю ссылочку для дальнейших ссылок на первоисточник.
Мне. Согласна с Виктором.
В какой проге вы делали карточки в конце? Или это просто Эксель/картинка?
Это скриншоты из Figma
В Figjam от Figma такое из коробки идет)
Коты такие коты)
Самые милые существа которые существуют
Классная статья, кто бы что не говорил, а мне всегда интересно узнать как работают разные студии). У всех свои подходы и методики и это здорово) Отдельное спасибо за ссылки
Всегда пожалуйста! Были рады рассказать о том как у нас все работает)
Хороший лонгрид с опытом работы. Интересен такой момент, если заказчику не принципиальны сроки, а важнее цена и качество идёт студия на такое или пытается навязать в итоге большее число разрабов за большую цену? Ну типа не нужен мне месяц работы со 100 сотрудниками, а давайте пилить год, но силами 10 сотрудников.
За другие студии говорить не будем, но для нас качество продукта на первом месте. А цену от срока разработки отделить никак не получится, так как именно из времени разработки строится стоимость проекта.
Хочу просто пасти котов а не вот это вот все
Настоящих? 🐱
Как п@сти котов, еб@ть собак, упр@влять проектами и не пл@кать?
Если узнаете - поделитесь!
Как всегда полезно, спасибо)
Рады слышать)
Не думаю, что фронтенд разработчики только анимируют кнопки и вставляют ссылки на этапе программирования :( Звучит так, как будто бы им не за что платить)
Конечно, это не так. Но иногда есть смысл не проваливаться в подробности, если статья не о фронтенд-разработке и не о работе программистов в целом)
Про котиков всегда интересно читать. Даже если это айти-котi
Котики - тот еще триггер! :)
Не смотря на минусы, которые отмечены в комментариях, все равно спасибо за материал.
🤝 Всегда пожалуйста)
Кучка зумеров пялящих в монитор и не создающих ничего, поэтому твой батя которому за 60 и ходит на завод, иначе мы совсем загнемся. Прекратите пиарить это тупиковое направление.
Как невыносимо много буковок! Я честно пытался прочитать полностью на экране телефона, но не выдюжил....
А остальную часть прочитайте с компьютера. Обещаем, будет полегче :)
https://www.youtube.com/watch?v=XMBXVLT50vw
Комментарий удален модератором
Сталина на них нет!
Комментарий недоступен
Фигасе цветет классовая ненависть.
На Reddit обратная ситуация, кстати - не любят конкретно тех-братанов, всяких "красивых людей" залетевших в индустрию цыганить. К инженерам вопросов нет.
А у нас - условный Маск кросавчег, остальные лоботрясы. Казалось бы, с социалистическими корнями должно быть наоборот. Хотя нет - логично.
Мы просто рассказали о том как строятся процессы у нас в студии) Никакой классовой вражды, честно-честно!
Комментарий недоступен
Немного не поняли ваш вопрос :(
В рабочее время. Это же не просто "бла бла" :)
Выделяем время, контролируем, чтобы по делу, а не о игрушках разговоры шли. О них в нерабочее разговариваем :)
Название статьи, конечно, очень интересное
Именно поэтому мы его и выбрали!
Комментарий недоступен
Можете поделиться, чего именно вам не хватило?
очень интересна...спасибо!
Рады, что статья оказалась для вас интересной)
у скрама есть одна очень большая проблема: он работает только когда вся команда работает над одной задачей. но стандартная история выглядит так: iOS уже делает новый экран, а Android ещё пилит прошлую фичу.
и тут получается что у iOS уже горит спринт и он не может помогать народу с Android с прошлым экраном. + часто в команде не равное кол-во android/ios, как итог разрыв в поставке ценности вырастает.
ну а дальше на дейликах получается, что большинству людей, вообще не интересно что делают другие, это по сути просто отчёт.
Скрам по сути предлагает выбор. Уменьшить количество задач в работе, но зато уменьшить и время выполнения конкретной задачи и сделать его предсказуемым.
iOS может заняться техдолгом/играть в настольный футбол, если его работа завершена над фичей, а не делать другие фичи, к которым ещё никто не приступил.