Тут бы понять, что вы конкретно вкладываете в словосочетание "оценивать вехи", как вы представляете это действие, чтобы попробовать ответить на ваш вопрос.
Ну есть дорожная карта, есть плановый (ну или прогнозируемый) срок выпуска релиза. И в этот горизонт планирования входят не только карточки из downstream-а, и даже не только из upstream-а, но даже и с этапа синтеза...
По мне так у всех задач lead time начинается с upstream. И все техники тюнинга и upstream и downstream и вынос рисков на ранний этап и прочее это про сокращение lead time и про устранение потерь.
А вот предсказуемость наверно может дать техника MMF (minimum marketable feature) тогда все фичи становятся примерно одинаковые.
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
_11. Декомпозируй правильно.
Коллеги за технику сначала пилят БД, потом сервисы потом UI. И им порой трудно обьяснить как сначала делать сценарий1 потом сценарий2 и тд.
Вот как объяснить?
Вопрос по сертификации PMI-ACP.
Что мне даёт сам факт подачи заявки, кроме того, что я могу записаться на экзамен и что начинает тикать время?
Можно ли подготовиться, а потом уже подавать заявку? А то читаю опыт других — все подают заявку и начинают усиленно готовиться, чтоб уложиться в 1 год.
Да, указанные причины вполне могут спровоцировать на рассказ (жалобы) про то как сейчас обстоят дела в проекте, какие проблемы хотелось бы порешать и тд.
Ну и в качестве знакомства сотрудник может сказать пару слов как долго он в проекте и к пришёл и где раньше работал и тд… Обычно такие вещи можно узнавать в курилке на обеде ну или за рюмкой чая :)
Но спровоцировать его на ретроспективное самокопание в собственных успехах, неудачах… Есть сомнение но надо пробовать))
Какого простите ляда сотрудники будут охотно отвечать на все ваши вопросы. О том чем занимался, каких результатов добился и тд. Это в статье вы понимаете что этот разговор ни к чему не приведёт (только знакомство) и что человек-процесс так же хорошо как и человек-результат. Но люди этого могут не понять и в головах большинства людей сидит стереотип, что результат важнее процесса. Н даром ведь мы когда обновляем резюме начинаем вспоминать именно о результатах.
Когда человек приходит к вам на собеседование, то у него есть цель в этих переговорах. Он хочет себя продать.
Доклад хороший в плане как налаживать контакт и доверие с подчинёнными, чтоб поддерживать их мотивацию на протяжении всей работы.
Но, это не может являться главным и уж тем более главным на период твоего испытательного срока. У тебя есть руководитель (-ли), он (они) взял тебя на работу, твоя должность не избрираемая. И в первую очередь надо соответствовать его ожиданиям. Не подумайте что я пишу как KPI-менеджер, как вы назвали. И я считаю правильным организовывать процесс так чтобы сотрудникам было комфортно в нем работать. Так они лучше смогут раскрыть себя, больше будут заряженны и в конце концов это принесёт больше пользы бизнесу. Но это стратегия. А тактика заключается в том чтобы соответсвовать ожиданиям конкретному руководителю или группе руководителей так или иначе влияющие на твой итог.
Не забывайте что и культура в организациях у всех разная. Где-то приветствуется директивый авторитарный стиль управления. Где-то руководитель наоборот будет собирать отзывы о тебе всех членов команды. И тогда вперёд, делай как сказано в докладе.
Резюмируя… Можно делать все как сказано, но все равно про###ть все полимеры не оправдав ожидания руководителя.
ну не надо сравнивать то что написано на заборе с тем что написано в законе… УЦ должны. И фраза в начале статьи неверная (про то что все уц делают что хотят и работают по своим правилам).
Но и я тоже не совсем прав: гражданский иск ничего не решит.
Суть проблемы в следующем: каждый УЦ может использовать свои правила удостоверения личности, в т.ч. по копиям документов через интернет.
Суть проблемы не в этом. УЦ не может использовать «свои правила». Согласно ФЗ-63 выдача сертификата квалифицированной ЭП должна проводиться только при личной явке.
Суть проблемы я бы сказал в том, что ответственность за нарушение этого пункта закона либо не прописана (я не в курсе), либо органы не очень то следят и расследуют эти нарушения.
Есть ли возможность подать в суд на УЦ? Гражданский иск. Доказать, что в момент выдачи сертификата (дата ведь известна) вы находились в другом месте, в другом городе (алиби, свидетели и тд), подпись на печатной форме не ваша (вот и графологам найдется применение). И привлечь за моральный и материальный ущерб.
А потом на основании вынесенного решения уже в ту инстанцию которая вас терроризирует.
Не пойму к чему этот комментарий?
Производители электричества хотят полностью окупить выработанное за будущий отрезок времени t электричество, значит они должны знать, сколько надо выработать. Заранее… Я об этом балансе.
А не про равенство сумм эдс и падений напряжения в закрытом контуре.
Как раз, когда мы спускаемся на микроуровень, то в дело вступают алгоритмы, роботы и методики прогнозирования.
Вот пример, в этой статье описывается одна из методик. Для меня эта статья ценна в первую очередь тем, что она ссылается на кучу других методик расчета. Что говорит о том, что математические обоснования в индустрии развиваются, реализуются и рано или поздно закрепятся в виде конкретного решения.
В моём понимании тимлид — это в первую очередь ведущий программист, во-вторую хорошо владеющий кодовой базой и только в-третью ответственный за принятие технических решений (каким способом — директивным, фасилититативным или еще каким — решать ему и его руководству).
Отсюда следует, что тимлида нельзя взять на работу и открыть такую должность нельзя :)
И соответственно, назначить его тоже нельзя.
Поэтому дико плюсую под этой цитатой!!!
делая лучшего разработчика тимлидом, вы теряете лучшего разработчика и получаете плохого менеджера
И собеседники вроде это подтверждают своим опытом (везде тимлид сам вырастал из команды).
Тимлид может и не вырасти и в моей практике управления проектами эта роль как правило была вырождена:
— сильных программистов в команде как правило было более одного
— со временем все они накапливали экспертизу в кодовой базе
— декомпозицию фичи на задачи брали по очереди (по крайней мере я старался распределять эту функцию, чтобы команда притиралась друг к другу, находила взаимопонимание и чтобы у других тоже была возможность проявить себя)
— технические решения уровня архитектора принимал архитектор
— распределение задач проходило либо по принципу кто-свободен-тот-и-берет либо по принципу ответственного-за-компонент — в зависимости от договоренностей;
— ну а решение конфликтов, фасилитацию, я всегда брал на себя как МП;
Ну есть дорожная карта, есть плановый (ну или прогнозируемый) срок выпуска релиза. И в этот горизонт планирования входят не только карточки из downstream-а, и даже не только из upstream-а, но даже и с этапа синтеза...
По мне так у всех задач lead time начинается с upstream. И все техники тюнинга и upstream и downstream и вынос рисков на ранний этап и прочее это про сокращение lead time и про устранение потерь.
А вот предсказуемость наверно может дать техника MMF (minimum marketable feature) тогда все фичи становятся примерно одинаковые.
И ещё такой вопрос как этот подход помогает оценивать вехи на дорожной карте?
В офисе ркн:
_11. Декомпозируй правильно.
Коллеги за технику сначала пилят БД, потом сервисы потом UI. И им порой трудно обьяснить как сначала делать сценарий1 потом сценарий2 и тд.
Вот как объяснить?
Что мне даёт сам факт подачи заявки, кроме того, что я могу записаться на экзамен и что начинает тикать время?
Можно ли подготовиться, а потом уже подавать заявку? А то читаю опыт других — все подают заявку и начинают усиленно готовиться, чтоб уложиться в 1 год.
Да, указанные причины вполне могут спровоцировать на рассказ (жалобы) про то как сейчас обстоят дела в проекте, какие проблемы хотелось бы порешать и тд.
Ну и в качестве знакомства сотрудник может сказать пару слов как долго он в проекте и к пришёл и где раньше работал и тд… Обычно такие вещи можно узнавать в курилке на обеде ну или за рюмкой чая :)
Но спровоцировать его на ретроспективное самокопание в собственных успехах, неудачах… Есть сомнение но надо пробовать))
И второе. Напишу отдельным постом.
Какого простите ляда сотрудники будут охотно отвечать на все ваши вопросы. О том чем занимался, каких результатов добился и тд. Это в статье вы понимаете что этот разговор ни к чему не приведёт (только знакомство) и что человек-процесс так же хорошо как и человек-результат. Но люди этого могут не понять и в головах большинства людей сидит стереотип, что результат важнее процесса. Н даром ведь мы когда обновляем резюме начинаем вспоминать именно о результатах.
Когда человек приходит к вам на собеседование, то у него есть цель в этих переговорах. Он хочет себя продать.
А какая цель у него в этом разговоре?
Доклад хороший в плане как налаживать контакт и доверие с подчинёнными, чтоб поддерживать их мотивацию на протяжении всей работы.
Но, это не может являться главным и уж тем более главным на период твоего испытательного срока. У тебя есть руководитель (-ли), он (они) взял тебя на работу, твоя должность не избрираемая. И в первую очередь надо соответствовать его ожиданиям. Не подумайте что я пишу как KPI-менеджер, как вы назвали. И я считаю правильным организовывать процесс так чтобы сотрудникам было комфортно в нем работать. Так они лучше смогут раскрыть себя, больше будут заряженны и в конце концов это принесёт больше пользы бизнесу. Но это стратегия. А тактика заключается в том чтобы соответсвовать ожиданиям конкретному руководителю или группе руководителей так или иначе влияющие на твой итог.
Не забывайте что и культура в организациях у всех разная. Где-то приветствуется директивый авторитарный стиль управления. Где-то руководитель наоборот будет собирать отзывы о тебе всех членов команды. И тогда вперёд, делай как сказано в докладе.
Резюмируя… Можно делать все как сказано, но все равно про###ть все полимеры не оправдав ожидания руководителя.
Но и я тоже не совсем прав: гражданский иск ничего не решит.
значит вся надежда на СК… ((
Суть проблемы не в этом. УЦ не может использовать «свои правила». Согласно ФЗ-63 выдача сертификата квалифицированной ЭП должна проводиться только при личной явке.
Суть проблемы я бы сказал в том, что ответственность за нарушение этого пункта закона либо не прописана (я не в курсе), либо органы не очень то следят и расследуют эти нарушения.
Есть ли возможность подать в суд на УЦ? Гражданский иск. Доказать, что в момент выдачи сертификата (дата ведь известна) вы находились в другом месте, в другом городе (алиби, свидетели и тд), подпись на печатной форме не ваша (вот и графологам найдется применение). И привлечь за моральный и материальный ущерб.
А потом на основании вынесенного решения уже в ту инстанцию которая вас терроризирует.
Производители электричества хотят полностью окупить выработанное за будущий отрезок времени t электричество, значит они должны знать, сколько надо выработать. Заранее… Я об этом балансе.
А не про равенство сумм эдс и падений напряжения в закрытом контуре.
Только один раз загрузить цепочку и валидировать каждый новый блок.
Криптокошелькам ведь не требуется постоянный доступ в интернет…
Вот пример, в этой статье описывается одна из методик. Для меня эта статья ценна в первую очередь тем, что она ссылается на кучу других методик расчета. Что говорит о том, что математические обоснования в индустрии развиваются, реализуются и рано или поздно закрепятся в виде конкретного решения.
Отсюда следует, что тимлида нельзя взять на работу и открыть такую должность нельзя :)
И соответственно, назначить его тоже нельзя.
Поэтому дико плюсую под этой цитатой!!!
И собеседники вроде это подтверждают своим опытом (везде тимлид сам вырастал из команды).
Тимлид может и не вырасти и в моей практике управления проектами эта роль как правило была вырождена:
— сильных программистов в команде как правило было более одного
— со временем все они накапливали экспертизу в кодовой базе
— декомпозицию фичи на задачи брали по очереди (по крайней мере я старался распределять эту функцию, чтобы команда притиралась друг к другу, находила взаимопонимание и чтобы у других тоже была возможность проявить себя)
— технические решения уровня архитектора принимал архитектор
— распределение задач проходило либо по принципу кто-свободен-тот-и-берет либо по принципу ответственного-за-компонент — в зависимости от договоренностей;
— ну а решение конфликтов, фасилитацию, я всегда брал на себя как МП;