Не могу с вами согласиться.
Здесь все зависит от подхода команды к данным «совещаниям». Если ежедневно собираться всей командой чтобы просто поприсутствовать и бегло рассказать о своей текущей работе, то в таких дейликах я смысла не вижу. Другое дело — использовать данный инструмент как способ быстрого решения возникших проблем, «блокеров» и эффективного перераспределения нагрузки в команде.
Возможно не всем командам подходит такой формат.
«Общий успех» — понятие довольно относительное и абстрактное. Наверное, включив фантазию и здравый смысл, его можно измерить применив к нему некий KPI в виде N-ой суммы маржи или N-ого количества предоставленных услуг. Но если вам удалось продать идею общего успеха команде, то разве это должно тормозить продуктивность команды?
Да зачем? Часто коллектив — это множество совершенно разных людей, разных полов, возрастов, интересов и достатка. Их объединяет только работа, и неформальная обстановка создает неловкость.
В этом то и вся проблема. Такая команда принесет меньше профита, поскольку люди в ней
больше заинтересованы в получении личной выгоды, нежели в преуспевании в общем деле. Думаю, что если неформальная обстановка создает в команде неловкость, то лучше лучше это исправлять, либо покинуть такую команду.
Я считаю, что если продуктивность команды растет и способствует увеличению маржи в компании, то почему бы не стимулировать эту команду? Ведь так она принесет еще больше пользы.
Разве хватило одной книги OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808, чтобы сдать на сертификат? Не пользовались дополнительными тестами?
Просто я сейчас как раз готовлюсь к экзамену 1Z0-808 и помимо тестов в данной книге использую дополнительные тесты из этой книги и тесты отсюда, и все еще нахожу, к сожалению, пробелы. Уж больно много опечаток в данной книге, пришлось постоянно заглядывать сюда.
Пусть поручение напишут сначала! А лучше – служебочку, да с согласованием, да не одним!
Похожая ситуация происходила на моей бывшей работе. Только там не было такой крутой коропоративной системы управления (была попытка внедрить что-то похожее, но все быстро вернулось на место), а была сплошная бюрократия.
Так вот там тоже была примерно такая же петрушка: враждующие отделы закидывали друг друга бумажными «служебками». Ну и потом, конечно же, прикрывались ими, мол «мы не смогли сделать это, потому что они не предоставили то, а служебку мы им направили». Более того, дошло до того, что служебку делали в двух экземплярах: один направляли получателю, а второй, с надписью «экз. получил» и подписью получателя, оставался у инициатора.
Приведу пример из своего скромного опыта.
Наша идея состояла в том, чтобы поднять в воздух первый в России 5-ти тонный беспилотный летательный аппарат (БПЛА). Эта идея насколько сплотила нас в команду мечты, а эта работа настолько была интересна, что мы работали не замечая времени. Не знаю, как в остальных конструкторских бюро, но в нашем (уже бывшем) бюро мы работали на запредельном энтузиазме до первого полета БПЛА.
Очень легко написать историю успеха, когда есть возможность работать «по совместительству».
Ну, чтобы у меня была возможность работать «по совместительству», мне пришлось чем-то пожертвовать. В моем случае — зарплатой. Мне пришлось перейти на половину ставки на основной работе, чтобы я мог устроиться на половину ставки стажером.
Я работал в отделе аэродинамики. И лично мне приходилось писать макросы на C++ для динамических CFD расчетов аэродинамики во Fluent. Но не более.
Думаю, что есть авиаинженеры которые кодят. Скорее всего, это ребята, которые занимаются авионикой и законами управления.
дауншифтингом из инженера с дипломом университета и спокойной работой в очередного программиста-вайтишника с дипломом шаражки и перспективой лёгкой замены на индуса
Я думаю, что это не есть дауншифтинг, поскольку я как был инженером, так им и остался. Просто сначала я был инженером-конструктором, а теперь я инженер-программист. Да и нет ничего плохого в расширении технического кругозора. Возможно, мне когда-нибудь пригодятся обе специальности ;)
Если бы еще на курсах учили правильно думать, т.е. алгоритмически.
Да, проблема курсов в том, что они не дают той логической базы, которую возможно дают в универе. Я ощутил эту нехватку знаний уже на стажировке. Но с другой стороны «а чего ж я хотел изучить за 70 часов?».
Боюсь однако что автор через несколько лет поймет что программирование это то же самое конструирование, тоже не всегда все так как хочется, да и выкидать код порой приходится.
Согласен с Вами! Думаю, везде существует обратная сторона медали.
Но никто и не говорил, что все будет идеально и легко ;)
Не могу с вами согласиться.
Здесь все зависит от подхода команды к данным «совещаниям». Если ежедневно собираться всей командой чтобы просто поприсутствовать и бегло рассказать о своей текущей работе, то в таких дейликах я смысла не вижу. Другое дело — использовать данный инструмент как способ быстрого решения возникших проблем, «блокеров» и эффективного перераспределения нагрузки в команде.
Возможно не всем командам подходит такой формат.
В этом то и вся проблема. Такая команда принесет меньше профита, поскольку люди в ней
больше заинтересованы в получении личной выгоды, нежели в преуспевании в общем деле. Думаю, что если неформальная обстановка создает в команде неловкость, то лучше лучше это исправлять, либо покинуть такую команду.
Просто я сейчас как раз готовлюсь к экзамену 1Z0-808 и помимо тестов в данной книге использую дополнительные тесты из этой книги и тесты отсюда, и все еще нахожу, к сожалению, пробелы. Уж больно много опечаток в данной книге, пришлось постоянно заглядывать сюда.
Похожая ситуация происходила на моей бывшей работе. Только там не было такой крутой коропоративной системы управления (была попытка внедрить что-то похожее, но все быстро вернулось на место), а была сплошная бюрократия.
Так вот там тоже была примерно такая же петрушка: враждующие отделы закидывали друг друга бумажными «служебками». Ну и потом, конечно же, прикрывались ими, мол «мы не смогли сделать это, потому что они не предоставили то, а служебку мы им направили». Более того, дошло до того, что служебку делали в двух экземплярах: один направляли получателю, а второй, с надписью «экз. получил» и подписью получателя, оставался у инициатора.
Приведу пример из своего скромного опыта.
Наша идея состояла в том, чтобы поднять в воздух первый в России 5-ти тонный беспилотный летательный аппарат (БПЛА). Эта идея насколько сплотила нас в команду мечты, а эта работа настолько была интересна, что мы работали не замечая времени. Не знаю, как в остальных конструкторских бюро, но в нашем (уже бывшем) бюро мы работали на запредельном энтузиазме до первого полета БПЛА.
Ну, чтобы у меня была возможность работать «по совместительству», мне пришлось чем-то пожертвовать. В моем случае — зарплатой. Мне пришлось перейти на половину ставки на основной работе, чтобы я мог устроиться на половину ставки стажером.
Я работал в отделе аэродинамики. И лично мне приходилось писать макросы на C++ для динамических CFD расчетов аэродинамики во Fluent. Но не более.
Думаю, что есть авиаинженеры которые кодят. Скорее всего, это ребята, которые занимаются авионикой и законами управления.
Я думаю, что это не есть дауншифтинг, поскольку я как был инженером, так им и остался. Просто сначала я был инженером-конструктором, а теперь я инженер-программист. Да и нет ничего плохого в расширении технического кругозора. Возможно, мне когда-нибудь пригодятся обе специальности ;)
Да, проблема курсов в том, что они не дают той логической базы, которую
возможнодают в универе. Я ощутил эту нехватку знаний уже на стажировке. Но с другой стороны «а чего ж я хотел изучить за 70 часов?».Когда я писал эту статью, я даже и не подозревал, что джавистов может быть больше, чем я думал…
Возможно я не вижу всей картины, поэтому моё первое впечатление, что джавистов мало, похоже, стало стереотипом.
Ну, мы ж не ищем легких путей :)
Согласен с Вами! Думаю, везде существует обратная сторона медали.
Но никто и не говорил, что все будет идеально и легко ;)