Здравствуйте, kograt, Вы писали:
K>Именно так, по другому нельзя, да и зачем? Не ужели Вы думаете что руководство должно пытаться экономить Ваше дешёвое время?
K>А весь этот оверхед всёравно оплатят, причём не кастомеры а их ещё более дешёвые рабочие в Китае. Глобализация рулит....
Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Да, МакДональдс — это хороший пример Никогда не хожу есть в подобные забегаловки. Мало ли что могут сделать с едой ненавидящие начальство сотрудники
Как там в анекдоте... "Вася, позови повара... вы посмотрите, он ест! Он ЭТО ест!!!!"
Здравствуйте, Xenia, Вы писали:
X>...и вот так — если не каждый день, то через день. Ну вот как можно работать в таких условиях???? Мое терпение иссякает стремительными темпами. А как у вас в конторе обстоят дела с организацией рабочего процесса?
Как я понял, основная ваша проблема в том, что нет development environment вообще. Контора может быть большой и как угодно забюрократизированной, но вся эта бюрократия должна касаться только production и соответственно deploy 2 production, где ей самое место. Очевидно, что релиз может легко занять один день и это нормально, но применять подобные policy для ежедневной работы — никому не нужный оверхед.
Так что, если нет возможности повлиять на ситуацию (что скорее всего), то только смириться. В качестве абстрактного совета могу рассказать, как было дело организованно у нас в одной немаленькой конторке.
Весь рабочий процесс разбивается на фазы:
1. Development. Происходит в development environment. С ней можно делать все что угодно на усмотрение команды. Билди когда хочешь, деплой на свой сервак, конфиги правь. Полная свобода. Даже нередко демонстрашки юзерам показываются в этом env.
2. QA. Фактически тот же dev env, т.к. баги надо фиксить побыстрее.
3. UAT. Когда QA завершился, то можно уже показывать юзерам. Все деплоится на другой сервак в UAT env и девелоперы с ним не работают. Понятно, что не очень будет здорово, если юзер увидит промежуточный фикс. Здесь тоже нет никакой бюрократии, если готова новая версия, то ее без бумажек деплоят достаточно быстро.
3. Production. Вот тут и всплывают все request, sign off-ы и прочая бумажная деятельность. Но, т.к. это происходит раз в месяц, то в принципе, это не страшно.
То же, что я увидел у вас очень напоминает кодирование прямо в production, что в любом случае не есть хорошо.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Нужно это несоответствие разрешить, довести до логического завершения в одну из сторон. iT>Или в сторону формализма и бюрократии — плотнее тестировать, и все такое. Тогда бы не зафиксили не протестированное и не собрались бы показывать не работающее.
А знаешь как обидно бывает в этом случае — вроде решение есть, оно работает, но одновременно его нет, потому что оно не прошло через все выпускающие руки
Здравствуйте, jhfrek, Вы писали:
X>>Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться.
J>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
Лично я "взрываюсь" на третьем-четвертом "переключении".
Чем совершеннее технически средство, тем более примитивные, никчемные и бесполезные сведения при его помощи передаются.(с)Станислав Лем
iT>>Или в сторону формализма и бюрократии — плотнее тестировать, и все такое. Тогда бы не зафиксили не протестированное и не собрались бы показывать не работающее.
J>А знаешь как обидно бывает в этом случае — вроде решение есть, оно работает, но одновременно его нет, потому что оно не прошло через все выпускающие руки
На обиженных воду возят.
Что хуже — задержать выпуск или поставить с ошибкой? Это очень depends и в разных ситуациях лучше разные крайности.
Где-то лучше подождать
Здравствуйте, L.Long, Вы писали:
LL>Здравствуйте, jhfrek, Вы писали:
X>>>Получается что отвлекся — вернулся к работе, пока вспоминал на чем остановился — уже опять надо отвлекаться.
J>>Хм, оказывается не только я один не люблю "переключать контексты" — тормозит такое переключение работу
LL>Лично я "взрываюсь" на третьем-четвертом "переключении".
Я взрываюсь на втором. Однажды прямо на начальство наорал (правда, оно временное было)
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит. Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
Не согласен.
В древности рабство было эффективно — для простых работ.
Для того чтобы сделать эффективно нетривиальную задачу — нужно мозги напрягать, соответственно умные (и мотивированные) люди.
А бизнес-процессы... Ну поставишь, будут люди друг другу отписывать, в отчетах отмечать что-нибудь, а проект завалится по причине некомпетентности исполнителей. И?
Здравствуйте, Igor Trofimov, Вы писали:
iT>На обиженных воду возят. iT>Что хуже — задержать выпуск или поставить с ошибкой? Это очень depends и в разных ситуациях лучше разные крайности. iT>Где-то лучше подождать
Эта да... Сам знаю что спешка иногда приводит к хужшим последствиям чем задержка Такова жисть
O>В качестве абстрактного совета могу рассказать, как было дело организованно у нас в одной немаленькой конторке.
Если не секрет, в какой стране находится "немаленькая конторка?"
X>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
принципиальные подробности...
и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
X>При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized. При copy-paste потерялся, знаете ли.
а это чья вина — ба, bug tracking system ?
X>Рабочий день закончен. Демонстрашка клиенту сорвана, но про такие мелочи уже никто не вспоминает.
все что надо было сделать — после добавления новой страницы посмотреть как она работает
Здравствуйте, Xenia, Вы писали:
X>Прошу считать нижеизложенное криком души Как же меня все это за-дол-ба-ло
X>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую.. Упс! Его ждал сюрпрайз — страница не работает! Команда девелоперов получает email полный скриншотов и всхлипов. При ближайшем рассмотрении выясняется, что один из классов не помечен атрибутом Serialized.
Не кажется ли вам, что винить нужно не "систему", не "дешёвого аналитика", а разработчика, который забыл поставить атрибут в коде?
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, kograt, Вы писали:
K>Читал весь тред, останусь при мнении что хорошо поставленные бизнес процессы и дешёвая рабочая сила при текучке 70 — 80% персонала ву год рулит.
Микрософт давно б загнулся если б у него 70-80% (при том что 10% уже повод бить в набат и возможно разгонять весь HR отдел к едрене фене) сотрудников в год сваливало.
K>Пример МакДональдс. Единственное где нужны дешёвые но квалифицированые кадры это стартап
не касаясь персоналий, пример неэффективной команды в тексте был взят не со стартапов, естественно. дело в том, что они как правило не выживают от поставленных бизнес-процессов
, уверен, и с образованием и с головой и с опытом и с хорошими зарплатами\самомнением — а видно как все ужасно неэффективно используется, не так ли?
Кстати именно любовь к такого рода "поставленным бизнес-процессам" которые все компании как одна начинают пытаться внедрять (что правильно) лишь немного встав на ноги и получив немного денег (спуская их потом на ветер и не замечая этого, что все таки мне уже не кажется правильным) и сподвигла меня написать текст
Внедрить процесс это как два пальца об асфальт. Внедрить эффективный процесс — вот что достойно уважения! Почему-то мне кажется что менее 7% компаний могут гордиться таким достижением
PS про McDonalds пример не очень корректный — что нового они делают? Они фактически сервис, но никак не разработка — зачем их в IT пихать для сравнения? Конечно, имеет смысл в их условиях пользовать "обезьян" по-максимуму — и то только если говорить о сотрудниках самого низшего звена. Не думаю что в управлении у них такая же текучка и низкие зарплаты — подумайте об этом
PPS Если же искать аналогию McDonalds в IT то это похоже на саппорт какого-то продукта. Да, бывает, имеет смысл сажать студентов с текучкой 70-80% — этого я не отрицал — в определенной ситуации такая стратегия может быть оправдана, кто ж спорит. Просто Вы немного передернули суть топика и уехали в McDonalds, а мы все ж в основной массе не оттуда
... << RSDN@Home 1.2.0 alpha rev. 653>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
А с каких пор тебя интересуют проблемы бизнеса и поставки клиентам?
Ты кто — программист или сейлз-менеджер или ПМ? — ты за это получаешь деньги?
Вот меня совершенно не волнует кому и что поставляется и в какие сроки... Это не моя работа и мне за ней денег не платят... Сроки — это проблема ПМа, работа с клиентаом — это проблема — сейлз-менеджера — они за это получают зарплату.
Если в фирме бардак, а это характерно для большенства фирм, то это уже проблемы менеджера по процессам и они волновать должны его, а не тебя...
Я вот вообще с места не сдвинусь — что бы занимтаься чужой работой.
Моя работа — писать софт, качественно и в срок (утвержденный со мной) — все остальное не моя забота, так зак за это я не имею денег.
Здравствуйте, ilya_ny, Вы писали:
_>Здравствуйте, Xenia, Вы писали: X>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>принципиальные подробности... _>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
... _>все что надо было сделать — после добавления новой страницы посмотреть как она работает
Очень часто бывает что при изменении кода, страничка, что работала раньше, перестает работать.
Пример: изменение code-behind для asp.net не всегда затрагивает страничку. Плюс, изменения бывают глобальными, и не всегда вспоминаешь, что и вот тут надо тоже протестировать.
Здравствуйте, mr_kern, Вы писали:
_>>Здравствуйте, Xenia, Вы писали: X>>>Вот например.. С утра пораньше, один из бизнес аналитиков (нанятый месяц назад свежий выпускник колледжа, нихрена не соображающий но зато дешевый — пашет за каких нибудь 40K в год и их таких у нас много) соизволил посмотреть работает ли новая веб-страница в приложении, которую он в тот день собирался показывать клиенту как готовую..
_>>принципиальные подробности... _>>и это же надо наглость какая — такой тупой и дешевый ошибку нашел. просто проверил работает ли новая страница. удивительно что дорогие и умные создатели странички не проверили работает ли она.
_>... _>>все что надо было сделать — после добавления новой страницы посмотреть как она работает
_>Очень часто бывает что при изменении кода, страничка, что работала раньше, перестает работать. _>Пример: изменение code-behind для asp.net не всегда затрагивает страничку. Плюс, изменения бывают глобальными, и не всегда вспоминаешь, что и вот тут надо тоже протестировать.
Баьенька, а на что существуют юнит- и веб-тесты? Как раз для этого.
Здравствуйте, olegkr, Вы писали:
O>Как я понял, основная ваша проблема в том, что нет development environment вообще. Контора может быть большой и как угодно забюрократизированной, но вся эта бюрократия должна касаться только production и соответственно deploy 2 production, где ей самое место. Очевидно, что релиз может легко занять один день и это нормально, но применять подобные policy для ежедневной работы — никому не нужный оверхед.
Может я чего-то не до конца понимаю, но в моем понимании hot fix в продуктивную систему напрямую касается production и, соответственно, deploy 2 production... не так ли?
Как же меня все это за-дол-ба-ло
для иллюстрации моего текста
