У нас в компании сделали гендерно нейтральный праздник 1-го марта. В итоге мы сами коллективом отметили и 8-е и 23-е и еще 1-го марта со всей компанией. Итого работодатель получил простой и потерю концентрации сотрудников над работой в офисе в течении нескольких часов 3 дня вместо 2-х ))). Так что какой то выгоды работодатель не получил по моему.
Я с командой из 22 человек дейли делал на 15-20 минут - итого команда в курсе что происходит, а время +- не влияющее на общую загрузку и потери, а вот поймать что кто то делает что-то не нужное или тормозит очень нужное помогает. Выгода больше чем расходы.
Нужно чутко следить что бы формат дейли соответствовал его ценности, не о погоде разговор, а четкое информирование команды.
Обычно классика ситуаций, схема ЛВС прежняя - перенесли стены, рабочие места целые отделы поменялись местами, а ЛВС строго по плану разместили, так что только постоянный регулярный контроль происходящего на стройке что бы по косвенным признакам различных активностей понять что твой план требует корректировки.
Чистая архитектура не сама цель, а средство. Вот например если мы уже имеем продукт у которого есть клиент, но он не оптимален и вызывает этим много проблем, тут уже есть смысл стремиться к чистой архитектуре и красоте. Так что если вы готовы за это платить, милости просим покупайте, а иначе можно и другой подход применить.
Если вы привлекаете команду, вы её прокачиваете и сплачаете, синхронизируетесь с исполнителем понимает ли он план, будет ли он ему следовать и т.п. да те же неочевидные идеи из опыта коллег получаете. Это дает в стратегическом плане много преимуществ. Но если вы разделяете ценности SCRUM, а если для вас это все непонятно и неинтересно то лучше даже не пробуйте станет хуже. Это просто один из вариантов организации работы в команде не более, с понятными и плюсами и минусами.
Главный вывод(по ощущениям от прочтения статьи), 1С платно, Сбис почти бесплатно...
Но итоговое сравнение цены близких по функциональности наборов не приведено (например в облачной 1С с сопоставимым набором опций). И статья не уровня хабра, а для еженедельника ИПешника. При всем уважении и даже некой симпатии к продуктам Сбис.
Само по себе наличие плана очень полезное условие получения результата, в социализме и в капитализме нужен план, в любом производстве нужен план, да даже просыпаясь с утра мы составляем себе мини план (встать почистить зубы открыть глаза и поползти на работу). Не стоит только делать план самой целью, это всего навсего инструмент, и им как молотком можно строить дом а можно разбивать витрины магазинов и морадерничать.
Мир не черно-белый мир полон перегибов компромиссов и ошибок. Неуправляемые рынки не редко приходят к кризису(и очень любят скатываться в монополии), как и в плановые модели приходят к кризису, так что ни одну из моделей абсолютно верной не назвать. Многие комментаторы под плановой моделью — подразумевают монстра пожирателя ресурсов работающего в убыток во славу божественной коровы «плана» подменяя провал конкретной социально-экономической модели СССР с провалом самой системы планирования.
Цифровизация экономики совершенствование механизмов планирования повышают и качество планирования и предсказуемость результата, но оставляет меньше места иновациям и изобретениям, пример автомобилестроение 60-80 смелые идеи дизайна эксперименты с компоновками, разные типы двигателей, а сейчас маркетинг в погоне за прибылью создает потребность и убеждает потребителя в том что это его потребность и мы наблюдаем не прогресс техники, а прогресс маркетинга (постоянный выход новых кузовов, при тех же технических решениях в основе, игры с экологичностью- те же масла longlife вся экологичность их в том что вы просто в два три раза дольше ездить должны не меняя масло и тем самым не нанося ушерб экологии заодно снижая ресурс двигателя и стимулируя более частую замену авто.). Справедливости ради может и вплюс более частая замена авто может и вправду прогресс быстрее из за этого.
Вы думаете, всё так просто? Да, всё просто. Но совсем не так.
(Альберт Эйнштейн)
В 1с когда делаю HTTP или Web сервис, по умолчанию значение для poolSize=«10» всего то его надо увеличить, для активно используемого сервиса пробовали и значение в «500» проблем не было.
Поддержу автора. Больше всего отталкивает от использования диаграмм попытки каждого разработчика и участника проекта изобрести свою нотацию, непредсказуемый уровень детализации, направления (разработчик мне как то нарисовал ракушку/спираль со стартом в правом нижнем углу, не сразу догадался как смотреть на его запутанную диаграмму). Не так сложно познакомиться со стандартом и соблюдать его.
Добавлю и свои пять копеек. Все это непонимание терминологии и её сути имеет корни в том что каждая компания или команда имеет свою версию бизнес-требований, ТЗ, нотаций (произвольно упрощают или усложняют их). И ты в итоге аналитик работает с какими то гибридами, зачастую имеющие связь только в названии со своими прародителями. Плюс к этому ширина ответственности аналитика его компетенций очень разнятся от компании к компании. По итогу многим они пользуются просто как все коллеги во круг, не понимая что это и зачем, просто по причине, что здесь так принято. И многие растут профессионально без плана и структуры развития, а просто из за более усложняющихся задач попутно прокачиваясь. Они даже не догадываются сколько они изобрели по пути велосипедов, сколько раз упустили из виду хорошие практики. Так же набор скилов которые нужен аналитику он не особо поддается стандартизации, нет четких гос.стандартов и программ. В итоге каждый идет своим путем и получается уникальным специалистом с рандомным набором скилов.
По итогу аналитик который должен все систематизировать и структурировать не умеет систематизировать и структурировать свои знания и развитие)))).
В PowerBI можно найти широкий спектр настраиваемых визуализаций, что и в FineBI, однако такой же вариативности настройки визуализаций получить не удастся.
Неплохо бы пример, чего именно не хватило в сравнении. Может случай неимоверно частный и не повлияет на массового пользователя, или же наоборот каждый день об это спотыкаться буду.
Хуже когда встречаешь разработчиков которые не мыслят в этой категории)))). По моему опыту не хотят систематизировать работу именно разработчики. Рассказываю пространное что не могут оценить сколько им нужно времени, не готовы делать декомпозицию глубже "Взять в работу-завершить работу". Постоянно вижу что именно разработчики указывают менеджерам что они не в праве требовать проработку архитектуры решения, это все ответственность ИТ не мешайте ИТ работать, а по итогу результат который не отвечает бизнес-требованиям и особо не полезен для бизнеса.
"Стоит не забывать что в каждом работнике сидит, ленивое лживое существо которое отчитается что сделало, а либо не сделает вообще или абы как."(продолжая логику @yerbabuena)
Ужас, ужас, оказывается людская сущность везде может показать свои негативные стороны и на уровне работника, менеджера, и даже собственник бизнеса может быть глуп некомпетентен и уничтожить свой бизнес.
Я Менеджер и испытываю обратные трудности, я уговариваю разработку заняться техдолгом, готов согласовать им на это все ресурсы и время, постоянно уговариваю протестировать нормально. в итоге получаю тяп ляп и в продакшен. Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Доказать полезность декомпозиции глубже чем Анализ-Написание ТЗ-Разработка-В продакшен. В общем как всегда не однозначно все. Здесь больше разработчиков потому правило хорошего тона поругать плохого HR и менеджер. а правда в каждом случае будет своя.
Ну и реально не тривиальная проблема поддержать необходимый баланс между красивым кодом и фичей полученной во время.
Мудрость приходит с годами, но иногда годы приходят одни. Очень много людей которые в профессии десятки лет но так внизу и болтаются и наоборот молодые которые очень быстро растут из-за упорства.
Потому на данный момент и применяется мера по разрешению параллельного импорта выборочно, к тем производителям которые перестали официально поставлять, и на данный момент временное разрешение параллельного импорта. Решением глобальным может стать создание комиссии или органа который мог бы выявлять факты необоснованного завышения правообладателем цены на рынке РФ и призывать его к ответу угрозой разрешения параллельного импорта. Универсального одного решения на все случаи жизни мне кажется не может быть, должна быть система обеспечивающая интересы общества.
Интересно, а как выглядит мировая практика в таких ситуациях, когда пострадало 100 клиентов понятно как судить, но если тысячи, или будет копеечная компенсация, либо банкротство компании. Насколько понимаю штраф в пользу государства в таких случаях выносят.
У нас в компании сделали гендерно нейтральный праздник 1-го марта. В итоге мы сами коллективом отметили и 8-е и 23-е и еще 1-го марта со всей компанией. Итого работодатель получил простой и потерю концентрации сотрудников над работой в офисе в течении нескольких часов 3 дня вместо 2-х ))). Так что какой то выгоды работодатель не получил по моему.
У вас левое рукопожатие на первой картинке, в арабском мире не оценят ;)
Я с командой из 22 человек дейли делал на 15-20 минут - итого команда в курсе что происходит, а время +- не влияющее на общую загрузку и потери, а вот поймать что кто то делает что-то не нужное или тормозит очень нужное помогает. Выгода больше чем расходы.
Нужно чутко следить что бы формат дейли соответствовал его ценности, не о погоде разговор, а четкое информирование команды.
Обычно классика ситуаций, схема ЛВС прежняя - перенесли стены, рабочие места целые отделы поменялись местами, а ЛВС строго по плану разместили, так что только постоянный регулярный контроль происходящего на стройке что бы по косвенным признакам различных активностей понять что твой план требует корректировки.
Чистая архитектура не сама цель, а средство. Вот например если мы уже имеем продукт у которого есть клиент, но он не оптимален и вызывает этим много проблем, тут уже есть смысл стремиться к чистой архитектуре и красоте. Так что если вы готовы за это платить, милости просим покупайте, а иначе можно и другой подход применить.
Если вы привлекаете команду, вы её прокачиваете и сплачаете, синхронизируетесь с исполнителем понимает ли он план, будет ли он ему следовать и т.п. да те же неочевидные идеи из опыта коллег получаете. Это дает в стратегическом плане много преимуществ. Но если вы разделяете ценности SCRUM, а если для вас это все непонятно и неинтересно то лучше даже не пробуйте станет хуже. Это просто один из вариантов организации работы в команде не более, с понятными и плюсами и минусами.
Главный вывод(по ощущениям от прочтения статьи), 1С платно, Сбис почти бесплатно...
Но итоговое сравнение цены близких по функциональности наборов не приведено (например в облачной 1С с сопоставимым набором опций). И статья не уровня хабра, а для еженедельника ИПешника. При всем уважении и даже некой симпатии к продуктам Сбис.
Только сейчас законодательство считает что норма 5-ть дней, а 6-й с дополнительной компенсацией, а если сделают 6-ти дневку, не будет компенсации.
Мир не черно-белый мир полон перегибов компромиссов и ошибок. Неуправляемые рынки не редко приходят к кризису(и очень любят скатываться в монополии), как и в плановые модели приходят к кризису, так что ни одну из моделей абсолютно верной не назвать. Многие комментаторы под плановой моделью — подразумевают монстра пожирателя ресурсов работающего в убыток во славу божественной коровы «плана» подменяя провал конкретной социально-экономической модели СССР с провалом самой системы планирования.
Цифровизация экономики совершенствование механизмов планирования повышают и качество планирования и предсказуемость результата, но оставляет меньше места иновациям и изобретениям, пример автомобилестроение 60-80 смелые идеи дизайна эксперименты с компоновками, разные типы двигателей, а сейчас маркетинг в погоне за прибылью создает потребность и убеждает потребителя в том что это его потребность и мы наблюдаем не прогресс техники, а прогресс маркетинга (постоянный выход новых кузовов, при тех же технических решениях в основе, игры с экологичностью- те же масла longlife вся экологичность их в том что вы просто в два три раза дольше ездить должны не меняя масло и тем самым не нанося ушерб экологии заодно снижая ресурс двигателя и стимулируя более частую замену авто.). Справедливости ради может и вплюс более частая замена авто может и вправду прогресс быстрее из за этого.
Вы думаете, всё так просто? Да, всё просто. Но совсем не так.
(Альберт Эйнштейн)
Поддержу автора. Больше всего отталкивает от использования диаграмм попытки каждого разработчика и участника проекта изобрести свою нотацию, непредсказуемый уровень детализации, направления (разработчик мне как то нарисовал ракушку/спираль со стартом в правом нижнем углу, не сразу догадался как смотреть на его запутанную диаграмму). Не так сложно познакомиться со стандартом и соблюдать его.
Добавлю и свои пять копеек. Все это непонимание терминологии и её сути имеет корни в том что каждая компания или команда имеет свою версию бизнес-требований, ТЗ, нотаций (произвольно упрощают или усложняют их). И ты в итоге аналитик работает с какими то гибридами, зачастую имеющие связь только в названии со своими прародителями. Плюс к этому ширина ответственности аналитика его компетенций очень разнятся от компании к компании. По итогу многим они пользуются просто как все коллеги во круг, не понимая что это и зачем, просто по причине, что здесь так принято. И многие растут профессионально без плана и структуры развития, а просто из за более усложняющихся задач попутно прокачиваясь. Они даже не догадываются сколько они изобрели по пути велосипедов, сколько раз упустили из виду хорошие практики. Так же набор скилов которые нужен аналитику он не особо поддается стандартизации, нет четких гос.стандартов и программ. В итоге каждый идет своим путем и получается уникальным специалистом с рандомным набором скилов.
По итогу аналитик который должен все систематизировать и структурировать не умеет систематизировать и структурировать свои знания и развитие)))).
Неплохо бы пример, чего именно не хватило в сравнении. Может случай неимоверно частный и не повлияет на массового пользователя, или же наоборот каждый день об это спотыкаться буду.
Хуже когда встречаешь разработчиков которые не мыслят в этой категории)))). По моему опыту не хотят систематизировать работу именно разработчики. Рассказываю пространное что не могут оценить сколько им нужно времени, не готовы делать декомпозицию глубже "Взять в работу-завершить работу". Постоянно вижу что именно разработчики указывают менеджерам что они не в праве требовать проработку архитектуры решения, это все ответственность ИТ не мешайте ИТ работать, а по итогу результат который не отвечает бизнес-требованиям и особо не полезен для бизнеса.
"Стоит не забывать что в каждом работнике сидит, ленивое лживое существо которое отчитается что сделало, а либо не сделает вообще или абы как."(продолжая логику @yerbabuena)
Ужас, ужас, оказывается людская сущность везде может показать свои негативные стороны и на уровне работника, менеджера, и даже собственник бизнеса может быть глуп некомпетентен и уничтожить свой бизнес.
Я Менеджер и испытываю обратные трудности, я уговариваю разработку заняться техдолгом, готов согласовать им на это все ресурсы и время, постоянно уговариваю протестировать нормально. в итоге получаю тяп ляп и в продакшен. Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Доказать полезность декомпозиции глубже чем Анализ-Написание ТЗ-Разработка-В продакшен. В общем как всегда не однозначно все. Здесь больше разработчиков потому правило хорошего тона поругать плохого HR и менеджер. а правда в каждом случае будет своя.
Ну и реально не тривиальная проблема поддержать необходимый баланс между красивым кодом и фичей полученной во время.
В России из за дешевого электричества не окупить быстро, у Финов дороже электричество, от того и окупаемость ближе.
Мудрость приходит с годами, но иногда годы приходят одни. Очень много людей которые в профессии десятки лет но так внизу и болтаются и наоборот молодые которые очень быстро растут из-за упорства.
Потому на данный момент и применяется мера по разрешению параллельного импорта выборочно, к тем производителям которые перестали официально поставлять, и на данный момент временное разрешение параллельного импорта. Решением глобальным может стать создание комиссии или органа который мог бы выявлять факты необоснованного завышения правообладателем цены на рынке РФ и призывать его к ответу угрозой разрешения параллельного импорта. Универсального одного решения на все случаи жизни мне кажется не может быть, должна быть система обеспечивающая интересы общества.
Интересно, а как выглядит мировая практика в таких ситуациях, когда пострадало 100 клиентов понятно как судить, но если тысячи, или будет копеечная компенсация, либо банкротство компании. Насколько понимаю штраф в пользу государства в таких случаях выносят.