Было 3 этапа собеседования:
- С ведущим разработчиком проекта в компании-нанимателе
- С ведущим разработчиком из компании-заказчика (уже на английском)
- С архитектором в компании-заказчика
В процессе собеседования выяснилось, что компания очень крупная, разработка ведется с использованием тех же инструментов, что и в первой компании. Все очень близко. Много задач по базе данных. Мне понравилось насколько подробно выспрашивали о технологиях, видно было, что уровень специалистов высокий и проект интересный.
Я решила принять предложение и прийти в компанию – поработать над интересной задачей и посмотреть как организованы процессы в американской компании. Надо здесь оговориться, что у меня были розовые очки. Я считала, что если компания в Америке, то все процессы у нее внутри налажены, руководители работают по принципам Стивена Кови и Ицхака Адизеса. К моему удивлению, это оказалось не так. Розовые очки были сняты, но нашлось много полезного и нового в работе компании.
1. Scrum
Сама методология с ее плюсами и минусами заслуживает отдельной статьи. Пока только скажу, что разработка делится на «спринты». Каждый спринт 2 недели. Предполагается, что все задачи будут закрыты за этот срок. Если вдруг, кто-то быстрее справится со своими задачами на спринт, то он подключится и поможет тем, кто не успевает. Оценка сложности задачи, на мой взгляд, очень полезная штука, проводится коллективно. Есть созвон 1 раз в неделю, в течение которого команда обсуждает еще неоцененные задачи и присваивает сложность – на закрытом голосовании. Потом, когда все проголосовали, уже видно, кто и сколько поставил, если есть большие расхождения в оценке — люди, которые оценили задачу, высказываются и обсуждают. В итоге группа приходит к общей оценке задачи. Штука длительная (редко занимает меньше 2-х часов), но, на мой взгляд, полезная. Во-первых, все в курсе основных задач. Во-вторых, такой метод позволяет более объективно оценить сложность и объем задачи.
2. Demo для руководства каждый спринт
Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты. В моей первой компании это был наболевший вопрос. Мы пробовали всякие отчеты, которые в итоге руководство не читало, в итоге вопрос повис, а непонимание осталось. А было такое простое решение. Презентация — раз в 2 недели (здесь по окончанию каждого спринта) с кратким обзором того, что было сделано понятным для бизнес-людей языком. Это дает руководству понимание, чем заняты люди и возможность понять туда ли движется проект.
3. All hands meeting
Вот это уже demo для сотрудников от руководства. С описанием основных приоритетов развития компании, достижений, и направления дальнейшего развития. На мой взгляд, замечательная штука. Она дает, во-первых, понимание людям какие задачи решает руководство и над чем оно работает. Во-вторых, это дает возможность соотнести свои приоритеты и принципы развития с приоритетами и принципами развития компании – так можно все время проверять, а по пути ли вам?
На таком «созвоне» обычно присутствует вся компания. И у всех есть возможность задать вопрос в эфире. Длится примерно 1 час. Проводится 1 раз в месяц или в квартал, в зависимости от компании.
4. Code review
Это больше техническая часть, но тоже очень полезная. Организация применения изменений в первой компании была следующая: разработчик вносил изменения, тестировал, отдавал тестировщику, затем следовала обязательная часть с подробным code review со стороны руководителя. Далее руководитель уже применял изменения к работающей системе. Мы не могли придумать как избавится от части с просмотром кода. А решение очень простое – code review должны делать сами разработчики. Только не тот, который писал код, а 2-3 других человека. Все их комментарии и замечания должны быть внимательно изучены и применены, либо автор-разработчик должен убедить своих коллег, что его решение лучше. Один момент – разработчики должны быть мотивированы делать code review. Иногда ожидание получения отзыва от других занимает столько же времени, сколько сама задача, а потом возвращаться к уже написанному коду и править его неудобно.
5. Bridge call во время проблемы
Если случается какая-то непредвиденная ситуация, например, загрузка ЦПУ на рабочем сервере возрастает до 90% и не удается в течение 5 минут устранить эту проблему, организуется Bridge call специалистов компании. Присутствуют DBA и ведущие разработчики.
Сначала я была довольно скептически настроена к таким «созвонам». Мне казалось, это должно скорее мешать решению проблемы. Однако я вижу эффективность этого метода – решение обычно находится и проблема разрешается. Такая совместная работа позволяет найти причину, благодаря тому, что несколько людей выдвигают предположения и занимаются поиском проблемы и ее решения.
Надеюсь, мой опыт будет вам полезен.
Комментарии (48)
mikhaill
22.07.2016 14:55+2А про минусы, пожалуйста
Nexiss
22.07.2016 15:32Поддерживаю!
KristinaMyLife
22.07.2016 22:15Хочу написать, только не в виде прямо минусов. На мой взгляд неэтично критиковать компанию «за глаза». Хочу собрать проблемы в управлении, с которыми сталкивалась и описать.
stardust_kid
22.07.2016 17:25-1Все программисты драпают с all hands, ну или пасьянс раскладывают, если встреча удаленная.
KristinaMyLife
22.07.2016 23:07Есть такая проблема. Мне кажется это от того, что люди не понимают зачем им эта информация, у них не возникало в ней нужды, а им ее уже дали.
Мне all hands очень нравится, я рада, что они есть. Можно провести параллель с бегущим отрядом и его командиром. На all hands командир периодически говорит, например «Эй, ребята, я бегу на Север, буду искать клад старого Джо, мне нужна будет помощь в поиске и раскопках.» И я могу для себя понять — хочу ли я туда, интересно ли мне это, насколько я считаю интересным и правильным бежать и раскапывать клад Джо. В общем я рада, что эта информация у меня есть.Fortop
23.07.2016 19:32Очень печально когда зам. техдира в описании процесса применяет такие слова как «мне очень нравится»
Это не критерий для оценки эффективности workflowKristinaMyLife
24.07.2016 14:19+1Спасибо за коммент. У меня часто рождается именно ощущение — хорошо, нравится, и если покопаться оно чем-то обосновано. Тут поделилась больше эмоциональной частью, и после вашего комментария, поняла. что не хватает собственно почему я считаю это полезным.
Чем на мой взгляд хороши all hands meeting?
- Повышения прозрачности со стороны руководства для сотрудников. Как следствие повышение доверия. Озвучивания целей и курса компании дает возможность человеку следовать этому курсу осмысленно, видя цель, больше вероятности, что к ней придешь. Это инструмент распространения видения цели на всю компанию. Сам каждый решит будет он лично двигаться к этой цели или нет, но знать о ней он по крайней мере будет.
- Формирования у разработчиков общей картины, видения происходящего. Я сталкивалась с такой проблемой – продукт разросся и разработчик пилит какую то маленькую часть, но при этом что вокруг нее не представляет. Нет понимания бизнес процессов и потребностей клиентов, на мой взгляд all hands способствует формированию общей картины.
- Возможность непосредственно пообщаться с руководством компании. Иногда у человека зреют какие-то вопросы, которые хочется задать собственнику (или директору) компании, но возможности это сделать нет. All hands такую возможность предоставляет.
Fortop
25.07.2016 13:25Да это собственно не мне.
Пользу от этого типа совещаний я знаю.
Вы в статью писать не забывайте :)
uamarshall
22.07.2016 17:44-1С подлючением! И это стоило статьи?
KristinaMyLife
23.07.2016 00:23+1Спасибо!
Про «стоило статьи» — бывает когда информацией хочется поделиться, и когда уже поделился со всеми друзьями и еще хочется, на мой взгляд, надо пробовать делиться в статье. Это как раз такой случай.
P0WERMIC
22.07.2016 18:01Bridge call конечно решает проблему, но зачастую прескучнейшее занятие, часто не хватает визуализации (расшаривания экрана) и многие участники не вовлечены активно, поэтому мягко говоря скучают и страдают фигней во время таких звонков.
KristinaMyLife
22.07.2016 23:00Визуализации очень не хватает. Особенно в сочетании с отсутствующим доступом это, например, меня доводит. Проблема есть, а сделать что-то с ней я не могу. Вид пытки такой. Как вариант озвучивать те действия, которые бы я сделала в этой ситуации и задавать вопросы.
BigD
23.07.2016 00:51У нас bridge call (или war room, если всё очень серьёзно) делается одновременно с webex — визуализация присутствует обычно.
Nashev
23.07.2016 16:26TeamViewer не способен от этого спасать?
GrigoryPerepechko
24.07.2016 00:19Неудобно. Чаще используют join.me
Nashev
25.07.2016 18:43Там же нет управления удалённым рабочим столом, чужой мышкой не подвигаешь! Чтоб активно вовлечься…
taulatin_one
22.07.2016 18:02+1Я бы добавил еще один пункт, который присутствует в американских компаниях, это совещание, которое собирают по окончанию проекта и где все участники высказываются, о положительных и отрицательных моментах которые были в проекте, а так же пожеланиях по улучшению работы в будущем.
KristinaMyLife
22.07.2016 22:13Да, тоже хорошая и полезная практика. На мой взгляд почти оно же — Sprint Retrospective, только проводится каждый спринт.
taulatin_one
22.07.2016 18:49+6Когда же эта ересь со Scrum отойдет в мир иной?
Я могу только описать свой месячный опыт наблюдателя в одной из американских корпораций.
Итак, по порядку. Stand up meeting. Народ рассказывает, как он классно написал SQL скрипт или что компьютер не имеет доступа к каким-то там ресурсам. Один, якобы, Java разработчик изучает отличия JRE от JDK. Судя по всему, монотонное жужжание некоторых докладчиков и не особо интересно остальным, но традиция должна быть соблюдена.
Каждое утро, три идиотских вопроса: Что сделано, Что планируется делать, Есть ли проблемы.
Тут настоящий разгул для талантливых с виду натур, можно вступить в бессмысленную полемику или даже повысить значимость своей работы, придумывая на ходу чрезвычайные сложности которые могут возникнуть при создании какого-либо тривиального действа.
Мой любимый демонстрация. Неделя не должна была пройти даром. Бизнес заказчик должен знать каждую деталь разработки, несмотря на то, что «пациент» еще не в полной кондиции, но бизнес хочет знать как там у нас с дела со всеми аспектами работы. Команда разработчиков загодя планирует демонстрацию, по сути это репетиция, которая должна быть близка к основному спектаклю.
Наиболее отчаянные разработчики показывают одну и ту же демонстрацию с небольшими, я бы сказал, косметическими изменениями. Последние, единогласно признаются существенным достижением в нашем проекте. Овации, благодарственные речи, судя по всему ничего не понимающих менеджеров. Радость и всеобщее ликование накрывают команду.
Идем дальше, планирование работ. И вот появляется список каких-то бизнес кейсов, они должны быть решены в следующей итерации этого безумного Scrum вертепа. По внешнему описанию и общему дух кейсы поступают прямо по спутниковому каналу с одного из центральных офисов на Марсе. Команда виртуозов сразу же берется за интерпретацию сиих даров высокоразвитых цивилизаций и производит оценку трудозатрат освоения новых технологий. Для этого участники сбора, по старинке, перекидываются в картишки, с некоторыми неясными непосвященному глазу номерками, которые являются некой заменой обычных трудозатрат. Общее голосование выносит свой безжалостный вердикт.
Тут вступает детальное обсуждение. 15 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса. Бизнес заказчик должен знать все детали сего сакрального действа, другой же части так же нужно всячески показать важность оного.
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
Я так и не смог дать ответ, почему дела обстоят именно так.
И не надо на себя примерять шкурку американского опыта, у них весьма распространен наем персонала по телефону. Я думаю, сложно сделать вывод, что мы из «Одной стаи» основываясь только на нескольких телефонных звонках. Вот и придумывают всякие управленческие костыли для работы с такими «мутными командами».
И да, минусы от адептов секты Scrum только приветствуются!KristinaMyLife
22.07.2016 22:07+1Я во многом согласна, именно поэтому хочу о самой методологии написать отдельно, мои ощущения и впечатления от работы во многом совпали с Вашими. В Scrum понравился именно подход к оценки задач.
taulatin_one
23.07.2016 00:04+1И не надо о ней писать. Чем меньше балбесов знают о каком-то сектантском учении тем лучше нам нормальным котам, которые гуляют сами по себе. Впрочем, даже знание этих бедняг не остановит нас.
KristinaMyLife
23.07.2016 00:15+3Сижу ржу, хочется поделится первоначальным шоком «Нет, правда, правда они тратят на это по 1 часу в день? и 2-3 на груминг в неделю? и еще retrospective и еще sprint planning? А когда работать?» и потом все-таки были положительные моменты, которые можно стянуть и применить с пользой.
Paskin
24.07.2016 13:32Для понимания, нужен ли скрам разработчикам или введен начальством в качестве «серебряной пули» — достаточно спросить как оценки времени выполнения задач соотносятся с реальностью и как это соотношение меняется со временем. Если это где-то 0.85-0.9 или растет к этому — скрам помогает. Если же программисты «промахиваются» раза в два и это не меняется месяцами — «что-то здесь не там».
Ну и для продвинутых/наглых — можно поинтересоваться кто ответственен за скрам-оф-скрамс и есть ли постоянный скрам-консультант. Если СОС организует начальство, а консультант торчит в фирме на постоянной основе — ничего путного из этого не выйдет, ритуалы так и останутся ритуалами а время будет бесполезно потеряно.
hoack
23.07.2016 00:57+1Любую идею можно саботировать или довести до абсурда. Скрам — это не методология, а фреймворк, который нужно подстраивать под каждый конкретный случай. В основе Скрама лежит некоторое количество вполне здравых мыслей — что команда способна сама себя регулировать; что двигаться стоит небольшими шагами, чтоб суметь при надобности быстро переориентироваться; что важно добиться понимания всеми того, что делается, в каком виде проект и сколько времени он займет; что в нынешних условиях быстро сделанный минимум лучше опоздавшего на полгода максимума…
А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.
Или планирование. Оно, на самом деле очень полезно хотя бы тем, что происходит проговаривание задач, и можно добиться того, что все понимают задачу одинаково. Ну, например, если стоит задача «Сделать автоматический бэкап данных», то очень возможно, что заказчик хочет иметь возможность записать данные в отдельный файл, а программист собирается создавать сложную облачную систему. Кроме того, благодаря такому проговариванию есть шанс отловить ситуацию, когда внешне простая задача на самом деле гораздо сложнее, чем кажется. У меня бывало несколько раз, что один из членов команды оценивал задачу в гораздо больше баллов, чем остальные, и при обсуждении указывал на подводные камни, которые он знал из своего опыта. Я уж и не говорю про то, что вычисляемая в результате скорость команды замечательно помогает при разговоре с начальством.
Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.
Ну, а то, что в Америке распространен наем по телефону — это, извините, чушь. Первое собеседование — да. А наем без встречи в реальной жизни — очень редко. Дешевле оплатить человеку билет и гостиницу, чем потом расхлебывать.
boblenin
23.07.2016 16:07+1Чтобы собрания любые, не только stand-up не были бесполезными требуется человек, который следит за обсуждением и прерывает не относящиеся к делу ветки. Сам Stand-Up происходит за 15 минут и при нормальном размере комманды 5-8 человек каждый должен высказаться, а это 3 или меньше минут на человека — не заскучаешь.
Бизнес заказчик должен знать каждую деталь разработки, несмотря на то, что «пациент» еще не в полной кондиции, но бизнес хочет знать как там
у нас с дела со всеми аспектами работы.
В скраме пациент всегда еще не в полной кондиции — продукт всегда улучшается. Если работа правильно распланирована — то каждая демо является кусочком новой функциональности для клиента (которую он может использовать в продакшене сразу после демы), либо исправлением существующей функциональности, котороая не устроила клиента.
Наиболее отчаянные разработчики показывают одну и ту же демонстрацию с небольшими, я бы сказал, косметическими изменениями.
Это показатель того, что product owners — не знают как правильно писать user story. Задача для scrum master — их научить. Если последний не видет этого или ничего не делает — его вина. Если у него нет достаточных полномочий — вина руководства.
И вот появляется список каких-то бизнес кейсов, они должны быть решены в следующей итерации этого безумного Scrum вертепа
Ну во-первых не бизнесс кейсов, а user story. Описание реальной проблемы реального пользователя которое может быть понятно любым членом комманды (пусть после некоторых объяснений).
Для этого участники сбора, по старинке, перекидываются в картишки, с некоторыми неясными непосвященному глазу номерками, которые
являются некой заменой обычных трудозатрат. Общее голосование выносит свой безжалостный вердикт.
А что там неясного с номерками? С точки зрения разработчика — смотришь на несколько задач A, B, C и D которые ты делал ранее и сравниваешь больше ли задача E, которую нужно оценить, чем каждая из них или меньше — и выдаешь результирующую циферку. Если ты выдал циферку которая сильно отличается от остальных — вы обсуждаете почему ты так думаешь и почему они думают по-другому. Если оказывается что ты учел что-то что они не видели — делается новая оценка, если их доводы оказываются убедительнее — ты можешь поменять свою.
С точки зрения тех, кто ведет проект — циферки накладываются на временную шкалу и сверяются с прошлым. Если в прошлом спринте сделали 10 пунктиков а в позапрошлом 8, а в позапозапрошлом 9 — они говорят 8 — это более менее гарантированная производительность комманды, 10 — это очень оптимистичная. А дальше берут приоритизированый и оцененый бэклог будующей работы и примерно прикидывают какая часть работы будет сделана в следующем спринте а какая не будет.
5 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса.
Для того, чтобы от этого отучиться надо некоторое время поработать в XP и освоить принцип YAGNI. Пока задача не в бэклоге и не приоритизирована — она не обсуждается. Как бизнесс так и техническая. Задача тех. лида засунуть технические задачи в бэклог и сторговаться с product owner о приоритетах (по большому счету обосновать необходимость решения).
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
Это правда. Встречи и общение возрастают при scrum. Если нравится сидеть и не отсвечивая колбасить код, то не самый оптимальный процесс. Но если хочется делать продукт и понимать зачем и для кого ты его делаешь — то скрам хороший.
Flammar
24.07.2016 02:00Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
В далёком лохматом 2005 бывший сотрудник компании, где я тогда работал, ушедший в американскую компанию, говорил, что якобы по их стандартам программист должен программировать 4 часа в день. Как я понял, под «программировать»имелся в виду непосредственно кодинг. Чем-то похоже.
amaksr
22.07.2016 20:02Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты.
Что-то фундаментально неправильно в такой компании.
А решение очень простое – code review должны делать сами разработчики. Только не тот, который писал код, а 2-3 других человека.
Поздравляю с открытием мира ITIL и одной из его практик — segregation of duties.
blackPeanut
22.07.2016 22:08Все методики по-своему хороши, но каждый пытается на этом заработать подавая под своим соусом (речь о консультантах, которые внедряют это все в компании).
Но на мой взгляд во всех этих митингах и стендапах очень много «воды» и очень мало «делать». Все собираемся кругом, водим хороводы, пожимаем руки и сидим с нахмуренными лбами, в итоге половина рабочего дня, а то и весь уходит в утиль без видимых продвижений.
Несомненно митинги нужны, но мне кажется, что люди на него должны приходить со следующим заполненным списком от старого, доброго Карнеги, который к эффективности и менеджменту имел посредственное отношение, но тем не менее этот воркфлоу позволяет действительно делать, а не встречаться и обсуждать, обсуждать, обсуждать. Такие совещания займут не более 15 минут, а эффекта намного больше.
Собственно сам список вопросов:
1. В чем сущность проблемы?
2. Какова причина возникновения проблемы?
3. Какие могут быть решения?
4. Какое решение вы предлагаете?KristinaMyLife
22.07.2016 22:11Да, отсутствия структуры собрания порождает кучу проблем и потерянное время, а как следствие если посчитать сколько компании обходятся все участники митинга в час, то можно увидеть, что все это стоит очень дорого.
boblenin
23.07.2016 16:12Согласен с вашей оценкой. И думаю что очень часто отсутствие смысла в собраниях — результат того, что нет того для кого обсуждаемая проблема важна. Как его называют champion. Того, кто как паравоз будет тащить обсуждение, ну и того кто будет противовесом и голосом разума.
GrigoryPerepechko
24.07.2016 00:25-2Вы б читали побольше чтоли. Меньше откровений было бы при смене работы.
KristinaMyLife
24.07.2016 00:31Посоветуйте, пожалуйста, например 3 книги самые полезные на ваш взгляд.
J_K
28.07.2016 19:26Запоздалый комментарий. Но все же лучше позже, чем никогда.
Очень меня интересует вопрос про оценку времени за решение задач. Из своего опыта я скажу — эта оценка никогда не бывает ни честной, ни точной. А знаете, почему?
Потому что работать 8 часов кряду невозможно — ну невозможно физически! Уходит время на отдых, туалет, иногда хочется встать и пройтись, почитать тот же хабр. По оценкам некоторых, на работу в среднем реально уходит до 4(!!!) часов в день.
И вот в таких условиях нам надо оценить задачу А и задачу Б.
Допустим, реальная оценка обеих задач — по 4 часа. Если придерживаться формального подхода, на их решение требуется один день (8 часов же!). Но так как никто реально не работает 8 часов, либо надо завышать оценки всегда, либо выделять официальное время на неработу (что никогда не делается). Именно поэтому разработчики стоят перед сложным выбором — или сказать правду и пахать как проклятые (во имя чего?) или работать нормально, но наврать с оценкой.
Кто может прокомментировать данную ситуацию?
Loengreen
29.07.2016 10:48Формально у вас 40 рабочих часов в неделю.
Но нормальный менеджер не будет планировать более 28 — 32 часов (если вы lead, то можно планировать еще меньше, если процесс работы с командой не формализован каким-то супер крутым образом).
«Запасные» 8 — 12 часов — коммуникация, переключения и прочие оверхеды (в том числе habr, мелкие фиксы до 15 мин., месседжеры, почта. ответы на вопросы и т.д.). Не забывайте, что это не отменяет поправочного коэффициента в оценке задач (x1,2 — 1,4).
В итоге 8 часовые задачи никогда не ставятся на 1 день (всегда на 2).
+ не забывайте, что оценка нужна в первую очередь для обратной связи. Опоздать не страшно (реально сложно учесть все нюансы), страшно никому об этом не говорить до последнего момента.
Но, возможно, я просто не сталкивался с методологиями, в которых запрещена корректировка оценки. :)J_K
29.07.2016 18:24Спасибо за ответ.
Полагаю, вы правы, и надо просто закладывать «запасное» время. Просто мне лично никогда не приходилось это наблюдать вживую. Если все решили, что задача на 8 часов (все — это скрам же!), то она всегда ставилась на один день. Наверное, мне просто не попадались нормальные лиды, которые понимали, что 8 часов на задачу не означают 8 часов, проведенных в офисе.
KristinaMyLife
01.08.2016 13:40Если брать конкретно эту компанию, был разговор на одном из митингов, что нужно планировать не более 6 часов в день работы, остальное почта, коммуникации. Как и сказал Loengreen.
На моей практике, если сравнивать работу без оценки задачи и с оценкой, я точно выберу с оценкой. Пусть даже немного неверной. Общая картина в итоге получается более предсказуемой и прозрачной. Кроме того навык оценки задач улучшается, чем больше оценки, тем точнее она становится (так по крайней мере в идеале). Конечно, бывает, что в середине выполнения вылезет какой-нибудь Кракен и задача займет сильно больше исходной оценки, но это скорее исключение, чем правило.
gtbear
Зам техдира не знает что такое scrum и удивляется демо?
Loengreen
Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить. А demo во многих компаниях быстро превращается в формальность и умирает.
Вопрос в том, чтобы заставить все эти полезные штуки работать (и тогда в них поверят и к ним подключатся разработчики).
Автор как раз пишет про процессы и как они настроены в его новой компании.
Автору: Спасибо, было интересно прочитать. Надо продолжать делать demo. :)
Помимо продолжительности, какие еще проблемы с покером планирования у вас были?
KristinaMyLife
Спасибо, рада что интересно.
С покером еще был следующий момент, если человек не разбирается в задаче и это не его область ему обычно сложно оценить сложность, тут обычно видно по голосованию — если все хорошо объяснено оценки довольно кучные. Оценки сильно отличающиеся от остальных как правило показывают, что человек, который их ставил не понимает как делать задачу.
Fortop
Потому что достичь достаточно высокой должности и не увидеть как его готовят в ай-ти надо ещё очень сильно постараться.
P.S. Лично я scrum не люблю. Но некоторые вещи вполне себе используются.
Достаточно вспомнить старое слово «планерка»
KristinaMyLife
Про scrum: одно дело знать о том, что это и совсем другое видеть как это реально используют.
Про демо: думаю нужно небольшое углубление. Понятно, что при изменении интерфейса программы или добавления новых функций их легко показать. Так как первая компания была продуктовая там большую долю времени занимала оптимизация работы системы. И вот осознания, что это тоже можно показывать на демо не было. А оказывается можно, на пальцах, высокоуровневым языком, но можно.
boblenin
Почему на пальцах и высокоуровневым языком? Графики, метрики и все с привязкой либо к производительности персонала либо к деньгам.