Смена персонала не признак развития, смена персонала — признак наличия организационных проблем.
Как говорится «крысы бегут с тонущего корабля»…
Я не уверен что у вас там «бизнес процессы» меняются и что они вообще в наличии, скорее нет чёткого позиционирования продукта. В любом случае это нужно обсуждать отдельно, можете отписать в скайп — расcкажу пару душещипательных историй.
Я и не отрицаю что есть очень много больних психологов и психиатров которые компенсируют свои расстройства посредством взаимодействия с клиентами — одни примитивные игры, генерализации и проекции…
Да, больные люди пытаются применить абстрактные принципы к реальным процессам без какой-либо адаптации.
Такое встречается вокруг да около.
У меня среди знакомых «идеальных» нет, но есть очень хорошие. По меркам Москвы их можно с уверенностью назвать идеальными — они умеют внедрять Agile методологии и проводить индивидуальную работу со всеми сотрудниками в рамках коллективa, анализировать социальные связи и предотвращать конфликты, в том числе и с заказчиками.
К сожалению это входит в моё NDA — я не могу называть имён, контор и методов которые были использованы (уже спросил).
Советую ознакомится со спецификой компенсаторных процессов шизоидного психотипа личности в рамках коллективов с потребностью постоянной интенсивной оптимизации трудовых процессов. Потом уж судить кто «правильный», а кто «неправильный»…
На самом деле, да, если бы программисты, и руководство, не компенсировалось в рамках рабочих процессов — SCRUM бы работал, но это нереально без аудита со стороны. Либо интенсификация рабочих процессов, и их оптимизации, должна полностью вытеснить возможность какой-либо компенсации, как это было, к примеру, в Яндексе.
Где ваша романтика, погребена под слоем казуальных «злых птиц»?
Как же сладка возможность запуска nmap на телефоне, и сборка/установка любых пакетов с исходников…
Текучка персонала — признак "дымохода" и "грибного менеджмента".
Опосля грибного менеджмента приходит «чайка-менеджмент» (seagull management) — пришёл поорал, оставил за собой кучи проектного дерьма, которые потом нужно разгребать персоналу…
Хотя лучше о них, как ни странно, почитать на лурке и поплакать.
Почти все организационные антипаттерны являются признаками компенсаторных процессов у руководства.
Опять же стоит решить вопросы
Выработки требований
Контроля качества
Долгосрочной поддержки
И все эти проблемы решаются через некоторое время.
Ничего не мешает писать и выкатывать MVP.
Выкатывать его на рынок с одними лишь приёмочными тестами, получить прибыль и обратную связь от потребителей, а потом внедрять эволюционный рефакторинг и добавлять больше тестов. Хотя профилировать решения нужно в любом случае.
Бюджета в 3000-4000$ обычно достаточно.
У нас так почти не умеют.
Я был в разных отралях — начиная от разработки железа и драйверов, заканчивая вэбом, десктопными и мобильными приложениями, SaaS'ами и PaaS'ами. 8 из 10ти проектов делались через одно место, по этому я так скептически ко всему отношусь.
Писал ТЗ по ГОСТу для автоматизированных систем в 160 страниц для аппаратной рекламной RTB-биржи реального времени на Virtex7 ПЛИСке. В принципе простой перечень пунктов и пустые странички с заголовками — 84 страницы. И ни одной бесполезной или несодержательной строчки, только требования жирным шрифтом должен, не должен, может, не может etc как в любом RFC. Все они стали основой для приёмочных тестов и части пользовательских историй. Хотя основные пользовательские истории были разработаны ещё до выработки требований прототипа устройства…
ТЗ — штука сложная, советую изучить вводную статью.
Я ориентировался по ней, и адаптировал ГОСТ 34.602-89, писал в Latex'е с ESKDx.
Ну, а я пытаюсь донести что подобного рода заказчики — примитивные недоразвитые индивиды которым не хватает мозга подумать о том что может быть через год, или если их любимый «выполнятор» заболеет или помрёт… или ему просто станет неинтересно.
Нянчится с такими — себя не уважать.
Главное не «довольность» заказчика, а отсутствие головной боли через N месяцев.
Согласен.
Любому бизнесу в первую очередь нужен продукт, а не методы его производства.
Основные Agile методологии в чистом виде неприменимы к существующим коллективам, и это прискорбно.
Разрабатывать и тестировать новые методологии индивидуально для каждого коллектива, со всеми его особенностями — вот важнейшая задача менеджера в наше время. При этом количество «бумажек» обычно стремится к нулю. Нужно проводить индивидуальную работу с каждым сотрудником и отслеживать социальные связи, в том числе и те которые не относятся к работе. Частенько отдельно нанимают психоаналитиков, я лично знаком с несколькими случаями их работы в рамках средних коллективов (до 100 человек) и в общем-то «мне хватило»…
Agile — это цель, а не средство… методология — средство, а не цель…
Почему-то абстрактные средства все считают универсальными и применимыми к реальным проектам.
Ну большинство «серой массы» эти вопросы действительно интересовать не должны…
А для всех остальных, по минимуму нужно обеспечить постоянное отслеживание версий и обновление всех зависимостей и движков/фреймворков, проводить аудит безопасности всех сторонних решений. имхо Где-то 70% сайтов на Wordpress взламывают как раз таки из-за древности движка и всех его зависимостей.
Опыт временем не меряют, его меряют способностью решать конкретные задачи, и разнообразием уже разрешённых.
Что бы 8 лет сайтики на CMS'ках да простых фреймворках штопать — много мозгу не нужно…
Давайте лучше поговорим как вы контролируете качество вашей продукции, и как вы решаете вопросы долгосрочной поддержки?
В 80% случаев ответ прост — никак.
Люди больны — люди желают компенсировать свои расстройства ставя организацию труда выше самого труда… что-то подходит больше, что-то подходит меньше. Не все Agile методологии одинаково полезны, но начинать нужно с адаптации существующих методологий и выработке новых, а не с попыток интеграции частных случаев, которые возможно в общем случае плохо подходят для больного коллектива.
По-этому заместь того что бы работать, менеджеры тупо копипастят всякую хрень с книжек — потому что она по идее «должна решить все проблемы как это было у одной абстрактной конторы в вакууме которую никто и никогда не видел».
Даже у таких абстрактных контор возникают проблемы и конфликты, и наши менеджеры не умеют их разрешать, вообще не умеют… об извлечении опыта история умалчивает.
имхо. В больном коллективе программист становится менеджером, в здоровом — остаётся программистом.
Абсолютно согласен — больные люди кидаются на красивую рекламу.
Большинство аббревиатур используемых в организации труда созданные не менеджерами, а маркетологами что бы можно было продать «священные знания святого бизнеса». Подсознательное желание больных людей делигировать ответственность даже мнимым артефактам является хорошей идей для монетизации.
Если рассматривать организацию работы сотрудников как задачу параллельного программирования со своей синхронизацией, и различными scatter/gather map/reduce операциями — все становится довольно просто.
Как говорится «крысы бегут с тонущего корабля»…
Я не уверен что у вас там «бизнес процессы» меняются и что они вообще в наличии, скорее нет чёткого позиционирования продукта. В любом случае это нужно обсуждать отдельно, можете отписать в скайп — расcкажу пару душещипательных историй.
Да, больные люди пытаются применить абстрактные принципы к реальным процессам без какой-либо адаптации.
Такое встречается вокруг да около.
К сожалению это входит в моё NDA — я не могу называть имён, контор и методов которые были использованы (уже спросил).
На самом деле, да, если бы программисты, и руководство, не компенсировалось в рамках рабочих процессов — SCRUM бы работал, но это нереально без аудита со стороны. Либо интенсификация рабочих процессов, и их оптимизации, должна полностью вытеснить возможность какой-либо компенсации, как это было, к примеру, в Яндексе.
Как же сладка возможность запуска nmap на телефоне, и сборка/установка любых пакетов с исходников…
Опосля грибного менеджмента приходит «чайка-менеджмент» (seagull management) — пришёл поорал, оставил за собой кучи проектного дерьма, которые потом нужно разгребать персоналу…
Хотя лучше о них, как ни странно, почитать на лурке и поплакать.
Почти все организационные антипаттерны являются признаками компенсаторных процессов у руководства.
Опять же стоит решить вопросы
И все эти проблемы решаются через некоторое время.
Выкатывать его на рынок с одними лишь приёмочными тестами, получить прибыль и обратную связь от потребителей, а потом внедрять эволюционный рефакторинг и добавлять больше тестов. Хотя профилировать решения нужно в любом случае.
Бюджета в 3000-4000$ обычно достаточно.
У нас так почти не умеют.
20 страниц при «полном Agile» — это диагноз, противоречит пункту 2.
Пускай почитают внимательно манифест.
Ну и ещё для полного счастья, советую ознакомится с реактивным манифестом.
ТЗ — штука сложная, советую изучить вводную статью.
Я ориентировался по ней, и адаптировал ГОСТ 34.602-89, писал в Latex'е с ESKDx.
Нянчится с такими — себя не уважать.
Главное не «довольность» заказчика, а отсутствие головной боли через N месяцев.
Любому бизнесу в первую очередь нужен продукт, а не методы его производства.
Основные Agile методологии в чистом виде неприменимы к существующим коллективам, и это прискорбно.
Разрабатывать и тестировать новые методологии индивидуально для каждого коллектива, со всеми его особенностями — вот важнейшая задача менеджера в наше время. При этом количество «бумажек» обычно стремится к нулю. Нужно проводить индивидуальную работу с каждым сотрудником и отслеживать социальные связи, в том числе и те которые не относятся к работе. Частенько отдельно нанимают психоаналитиков, я лично знаком с несколькими случаями их работы в рамках средних коллективов (до 100 человек) и в общем-то «мне хватило»…
Agile — это цель, а не средство… методология — средство, а не цель…
Почему-то абстрактные средства все считают универсальными и применимыми к реальным проектам.
busfactor == 1 неприемлем
А для всех остальных, по минимуму нужно обеспечить постоянное отслеживание версий и обновление всех зависимостей и движков/фреймворков, проводить аудит безопасности всех сторонних решений. имхо Где-то 70% сайтов на Wordpress взламывают как раз таки из-за древности движка и всех его зависимостей.
Что бы 8 лет сайтики на CMS'ках да простых фреймворках штопать — много мозгу не нужно…
Давайте лучше поговорим как вы контролируете качество вашей продукции, и как вы решаете вопросы долгосрочной поддержки?
В 80% случаев ответ прост — никак.
По-этому заместь того что бы работать, менеджеры тупо копипастят всякую хрень с книжек — потому что она по идее «должна решить все проблемы как это было у одной абстрактной конторы в вакууме которую никто и никогда не видел».
Даже у таких абстрактных контор возникают проблемы и конфликты, и наши менеджеры не умеют их разрешать, вообще не умеют… об извлечении опыта история умалчивает.
имхо. В больном коллективе программист становится менеджером, в здоровом — остаётся программистом.
Большинство аббревиатур используемых в организации труда созданные не менеджерами, а маркетологами что бы можно было продать «священные знания святого бизнеса». Подсознательное желание больных людей делигировать ответственность даже мнимым артефактам является хорошей идей для монетизации.
Если рассматривать организацию работы сотрудников как задачу параллельного программирования со своей синхронизацией, и различными scatter/gather map/reduce операциями — все становится довольно просто.