Вопрос «кем вы видите себя через 5 лет» в зависимости от опыта соискателя, контекста и его мировоззрения может интерпретироваться совершенно по-разному, как и со стороны работодателя, который не понятно что хочет вытянуть из соискателя таким вопросом. Но самое поганое, что работодатель может совершенно по-разному интерпретировать ещё и сам ответ. Т.е. у нас выходит аж три точки, где может исказиться понимание происходящего.
А ведь работодатель мог спросить «Какие ваши ожидания от работы в нашей компании» (ну или вариации на тему вопроса), чтобы хоть как-то прояснить цели трудоустройства, помимо денежного интереса: будь то вызов с точки зрения сложности задач, карьерный рост или что-либо ещё.
А вообще ради экономии времени слишком многое хотят люди узнать на собеседованиях, что просто невозможно, несмотря на то, что это разумно в крупных организациях, которых, казалось бы, меньше в абсолютном выражении по сравнению со средними и небольшими компаниями, где найм сотрудников можно осуществлять без клише.
Себя увольте. Нет в скраме никаких стори поинтс, потому как в скраме вообще элементы бэклога/спринтлога могут быть вовсе не в формате User Story описаны.
В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
Удивительно, адекватная статья про scrum без всякого бреда, хотя первое впечатление по заголовкам было обратным.
Смысл заголовка статьи правда так и остался для меня тайной.
И Agile — набор ценностей и принципов, а не тактик. Тактика это всё же нечто, что можно применить будучи беспринципным и с ценностями насекомого.
А вам запрещают курить? Если вы про ограничение курения в некоторых местах, то это к теме не совсем относится, потому как ограничения временного характера (на время, пока вы где-то находитесь), а не жизненного выбора курить или не курить. Автомобилистам тоже запрещено по тротуарам ездить, не говоря о том, что «справлять нужду» на остановке тоже запрещено, хотя мочеиспускание в отличии от курения — это врождённая потребность :)
Жёсткие нормы, пожалуй, хорошо, но не понимаю как это подталкивает производителей решать за меня, что мне через 5 лет необходимо будет поменять авто? Может быть нормы не изменяться к тому моменту, а может быть мне финансово проще будет платить повышенный налог на мой автомобиль за не соответствие современным нормам. Несмотря на то, что эти нормы тоже, казалось бы, не предоставляют выбора, но это относится всё же к жизни в государстве, эдаким «коллективным договорённостям» на которые мы идём, проживая в том или ином государстве. Что касается компаний, то они это делают в одностороннем порядке исключительно для извлечения прибыли под красивым предлогом «благих целей».
Принципиально оплата и банковскими картами ничем не отличается от оплаты наликом, где вместо карты выступает кошелёк :)
Вопрос относительного удобства. Сейчас всё это пока выглядит улучшением «колеса», а не инновационными решениями.
В данном случае, вместо того, чтобы просить номер карты знакомого (ну или даже вместо сохранённого где-то в контактах, правда не знаю кто так делает), куда перевести деньги ты можешь тупо кликнуть на номер в контактах и таким образом перевести деньги товарищу. При этом знакомый этот сможет ещё и выбрать на какую из карточек зачислить перечисленные денюжки. Эдакое слабое связывание, где тебе не обязательно знать, какие карты вообще есть у человека, которому тебе надо перевести деньги и вообще лишний раз тревожить.
Правда это всё утопия, потому как из-за большого количества решений приходится всё равно перед отправкой допытываться каким способом перевести деньги получателю и чаще, пока, это card2card.
Сам по себе Agile — это набор ценностей и принципов, а не подход к разработке. Ну и не говоря о том, что, не смотря на форму и качество, существует не только в аутсорсе. :)
И водопад и гибкие подходы в разработке хороши каждый в своём случае и когда неверно делают выбор процесса — вот тогда и начинается неразбериха и недовольство выбранным подходом.
У автора и с Agile тоже не всё будь здоров, так что статья и вышла половинчатой какой-то, с точки зрения знаний и правды :)
Я так понимаю вы очень много работали по водопаду, а по какому-нибудь из Agile подходов вы работали?
У вас дикий какой-то замес получается. :)
Просто исходя из поверхностной оценки складывается впечатление, что была когда-то классическая иерархическая система, на которую решили натянуть «модни-молодёжни» Agile, без понимания того, что при этом должны быть произведены в том числе и структурные изменения (не говоря о способе мышления в целом), а не некоторые событийные в виде Дейли скрамов и Спринтов, чтобы новые процессы привнесли свою пользу)
Меня просто смущает, например, наличие одновременно и PO и PM — какие у PM обязанности? Lean повлиять на такую ситуацию не мог, а в Scrum подобного нет.
Например, если взять тот же Scrum, то в целом обязанности аналитика размазаны между PO и командой разработки. Теоретически-то человек с компетенциями Аналитика вполне может вписаться в команду разработки в случае, если команда разработки не справляется самостоятельно.
А который из Agile-подходов у вас используется?
Проекта. Вы можете просто делать отметки в самих проектах, которые прошли due dill. Собственно те, которые были «убиты» due dil'ом так же можно пропускать к сбору средств, если вы считаете, что могут быть среди них прорывные продукты, но пользователь хотя бы будет видеть риски и понимать, что цифра оценки компании взята с совсем потолка, но если он сам поверит в идею сможет в неё вложить деньги не взирая на риск.
Портфель собирать это нормально, я согласен, но в странах СНГ совсем всё плохо с квалифицированными инвесторами, которые за бугром, на подобных краудинвестинг платформах, составляют львиную долю денег, вкладываемых в проекты, и есть предположение, что стоит подумать о некоторой «защите» инвесторов на вашей платформе. Мне как пользователю, хотелось бы может вкладывать больше денег в проекты, но из-за отсутствия времени на самостоятельный глубокий анализ каждого проекта, хотелось бы видеть какую-нибудь предварительную оценку от платформы.
Раздел же «безумных идей» жил бы отдельной жизнью, и возможно на иных условиях, а то pre-seed, уверенно считающий, что стоит $600k и окупится через год, похож больше на команду фантазёров.
Если вы собираетесь играть в долгую, а не закрыться к 2015 году, то стоит подумать о репутационных рисках: делать хоть какую-нибудь предварительную проверку компаний, размещающихся на вашей платформе, их владельцев, чтобы уж отборнейший шлак не допускать к сбору средств. ;) В идеале делать due dil вашей платформой.
С точки зрения разработки и доносимой ценности Заинтересованным лицам (к которым относится и заказчик) scrum несколько интереснее, да. В том числе демонстрации по окончании каждой итерации позволяют Заинтересованным лицам не находится в неведении, а на каждой демонстрации понимать на каком этапе вы находитесь и в какую сторону движетесь. Принимая от них же обратную связь можно в том числе будет корректировать путь к достижению цели.
В принципе, многие беды из-за отсутствия нормальной коммуникации между людьми, в том числе в командах разработки. То же непонимание Заказчика, как заинтересованного лица, при решении задач из категории «технического долга» корнем лежат в том, что эти проблемы скорее всего не были объяснены ему с близкой ему экономической точки зрения, чем бизнесу это грозит в будущем и так далее.
Думаю, что если вы способны будете объяснить сильные стороны нового для заказчика подхода для разработки с экономической точки зрения, то у него не будет причин наставивать на чём-то другом. Главное быть честным перед ним и рассказывать всё как есть и в этом случае он будет лучше вовлечён в проект и, возможно, сможет помочь в каких-то вопросах решение которое у него займёт меньше времени, чем у вас, что в итоге ему принесёт профита больше.
Если это первый проваленный спринт, то да, почему нет? Если в каком-либо последующем спринте произойдёт такая же ситуация (такие же условия провала), то это уже повод подумать о новой команде, потому как они не оценили, почему они провалили спринт и ничего для этого не сделали, чтобы в будущем этого не повторялось. Для команды и существуют ретроспективы, чтобы оценивать, что понравилось за спринт и что можно улучшить, в том числе проанализировать, почему завалили спринт/конкретную историю (если конечно завалили) и что можно сделать в следующий раз, чтобы дойти до конца спринта «без потерь».
Но это всё разговоры о сферическом коне в вакууме и ситуации бывают разные. У меня есть примеры и где несколько спринтов подряд комадна разработки фейлила одну и ту же критически важную фичу для бизнеса и Владельцу продукта при этом было ОК, ибо в основном провалы были из-за внешних зависимостей, о которых и Команда разработки, и Владелец продукта знали заранее до начала спринта, ибо ещё на груминге они все вылезали.
У них со временем скрам превратился, конечно, в эдакое подобие его и им скорее всего лучше бы подошёл водопад, но они из скрама почерпнули часть полезных идей, как для команды, так и для бизнеса в целом: если вкратце, то это пожалуй умная работа в бэклогом и улучшенная/налаженная коммуникации как внутри команды, так и в целом со своими клиентами.
Но у меня складывается впечатление, что вы пытаетесь всё же совместить водопад со скрамом. Точнее вы как команда разработчиков пытаетесь работать по скраму, а заказчик привык работать с водопадом и вы ему не рассказали правил игры в которую подписались играть. В таком случае вы находитесь в заведомо проигрышной ситуации.
Вы пытаетесь совместить обычный водопад со скрамом, поэтому у вас возникают такие проблемы.
В скраме фиксированная оплата за спринт, фактически — нет никаких стоимостей проектов или чего-то подобного. Заказчик по истечении некоторых спринтов (за каждый из которых вы привнесли ему какую-то Ценность на основе его ожиданий) либо доволен результатами и продолжает с вами колбасить проект, либо нет и ищет других. При этом заказчику очень просто сравнивать ценно ли то, что вы сделали за спринт с тем, сколько он за него отвалил денег.
А ведь работодатель мог спросить «Какие ваши ожидания от работы в нашей компании» (ну или вариации на тему вопроса), чтобы хоть как-то прояснить цели трудоустройства, помимо денежного интереса: будь то вызов с точки зрения сложности задач, карьерный рост или что-либо ещё.
А вообще ради экономии времени слишком многое хотят люди узнать на собеседованиях, что просто невозможно, несмотря на то, что это разумно в крупных организациях, которых, казалось бы, меньше в абсолютном выражении по сравнению со средними и небольшими компаниями, где найм сотрудников можно осуществлять без клише.
В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
Смысл заголовка статьи правда так и остался для меня тайной.
И Agile — набор ценностей и принципов, а не тактик. Тактика это всё же нечто, что можно применить будучи беспринципным и с ценностями насекомого.
Жёсткие нормы, пожалуй, хорошо, но не понимаю как это подталкивает производителей решать за меня, что мне через 5 лет необходимо будет поменять авто? Может быть нормы не изменяться к тому моменту, а может быть мне финансово проще будет платить повышенный налог на мой автомобиль за не соответствие современным нормам. Несмотря на то, что эти нормы тоже, казалось бы, не предоставляют выбора, но это относится всё же к жизни в государстве, эдаким «коллективным договорённостям» на которые мы идём, проживая в том или ином государстве. Что касается компаний, то они это делают в одностороннем порядке исключительно для извлечения прибыли под красивым предлогом «благих целей».
Вопрос относительного удобства. Сейчас всё это пока выглядит улучшением «колеса», а не инновационными решениями.
В данном случае, вместо того, чтобы просить номер карты знакомого (ну или даже вместо сохранённого где-то в контактах, правда не знаю кто так делает), куда перевести деньги ты можешь тупо кликнуть на номер в контактах и таким образом перевести деньги товарищу. При этом знакомый этот сможет ещё и выбрать на какую из карточек зачислить перечисленные денюжки. Эдакое слабое связывание, где тебе не обязательно знать, какие карты вообще есть у человека, которому тебе надо перевести деньги и вообще лишний раз тревожить.
Правда это всё утопия, потому как из-за большого количества решений приходится всё равно перед отправкой допытываться каким способом перевести деньги получателю и чаще, пока, это card2card.
И водопад и гибкие подходы в разработке хороши каждый в своём случае и когда неверно делают выбор процесса — вот тогда и начинается неразбериха и недовольство выбранным подходом.
У автора и с Agile тоже не всё будь здоров, так что статья и вышла половинчатой какой-то, с точки зрения знаний и правды :)
Я так понимаю вы очень много работали по водопаду, а по какому-нибудь из Agile подходов вы работали?
Просто исходя из поверхностной оценки складывается впечатление, что была когда-то классическая иерархическая система, на которую решили натянуть «модни-молодёжни» Agile, без понимания того, что при этом должны быть произведены в том числе и структурные изменения (не говоря о способе мышления в целом), а не некоторые событийные в виде Дейли скрамов и Спринтов, чтобы новые процессы привнесли свою пользу)
Меня просто смущает, например, наличие одновременно и PO и PM — какие у PM обязанности? Lean повлиять на такую ситуацию не мог, а в Scrum подобного нет.
А который из Agile-подходов у вас используется?
Не очень понятно, как всё, кроме «Руководства менеджера», без притягивания за уши как-то попадает в GTD, не говоря уж о Agile. :)
В Slack же можно управлять уведомлениями для каждой комнаты (и для разных устройств), чем как правило все в нашей команде и пользуются.
Портфель собирать это нормально, я согласен, но в странах СНГ совсем всё плохо с квалифицированными инвесторами, которые за бугром, на подобных краудинвестинг платформах, составляют львиную долю денег, вкладываемых в проекты, и есть предположение, что стоит подумать о некоторой «защите» инвесторов на вашей платформе. Мне как пользователю, хотелось бы может вкладывать больше денег в проекты, но из-за отсутствия времени на самостоятельный глубокий анализ каждого проекта, хотелось бы видеть какую-нибудь предварительную оценку от платформы.
Раздел же «безумных идей» жил бы отдельной жизнью, и возможно на иных условиях, а то pre-seed, уверенно считающий, что стоит $600k и окупится через год, похож больше на команду фантазёров.
С точки зрения разработки и доносимой ценности Заинтересованным лицам (к которым относится и заказчик) scrum несколько интереснее, да. В том числе демонстрации по окончании каждой итерации позволяют Заинтересованным лицам не находится в неведении, а на каждой демонстрации понимать на каком этапе вы находитесь и в какую сторону движетесь. Принимая от них же обратную связь можно в том числе будет корректировать путь к достижению цели.
В принципе, многие беды из-за отсутствия нормальной коммуникации между людьми, в том числе в командах разработки. То же непонимание Заказчика, как заинтересованного лица, при решении задач из категории «технического долга» корнем лежат в том, что эти проблемы скорее всего не были объяснены ему с близкой ему экономической точки зрения, чем бизнесу это грозит в будущем и так далее.
Думаю, что если вы способны будете объяснить сильные стороны нового для заказчика подхода для разработки с экономической точки зрения, то у него не будет причин наставивать на чём-то другом. Главное быть честным перед ним и рассказывать всё как есть и в этом случае он будет лучше вовлечён в проект и, возможно, сможет помочь в каких-то вопросах решение которое у него займёт меньше времени, чем у вас, что в итоге ему принесёт профита больше.
Но это всё разговоры о сферическом коне в вакууме и ситуации бывают разные. У меня есть примеры и где несколько спринтов подряд комадна разработки фейлила одну и ту же критически важную фичу для бизнеса и Владельцу продукта при этом было ОК, ибо в основном провалы были из-за внешних зависимостей, о которых и Команда разработки, и Владелец продукта знали заранее до начала спринта, ибо ещё на груминге они все вылезали.
У них со временем скрам превратился, конечно, в эдакое подобие его и им скорее всего лучше бы подошёл водопад, но они из скрама почерпнули часть полезных идей, как для команды, так и для бизнеса в целом: если вкратце, то это пожалуй умная работа в бэклогом и улучшенная/налаженная коммуникации как внутри команды, так и в целом со своими клиентами.
Но у меня складывается впечатление, что вы пытаетесь всё же совместить водопад со скрамом. Точнее вы как команда разработчиков пытаетесь работать по скраму, а заказчик привык работать с водопадом и вы ему не рассказали правил игры в которую подписались играть. В таком случае вы находитесь в заведомо проигрышной ситуации.
В скраме фиксированная оплата за спринт, фактически — нет никаких стоимостей проектов или чего-то подобного. Заказчик по истечении некоторых спринтов (за каждый из которых вы привнесли ему какую-то Ценность на основе его ожиданий) либо доволен результатами и продолжает с вами колбасить проект, либо нет и ищет других. При этом заказчику очень просто сравнивать ценно ли то, что вы сделали за спринт с тем, сколько он за него отвалил денег.