Pull to refresh
1
-0.1
Send message

На мой взгляд это не мистическое мышление, а такие условия. Редкий руководитель имеет совесть и большие яйца, чтобы убедить инвестора раскошелиться и редкий инвестор будет слушать такого руководителя о необходимости постоянно вкладываться. Их же сочетание так и вообще краснокнижное. У руководителя как правило KPI - это экономия на всём, что возможно (эффективность - это больший результат за меньшие средства - ведь так почти все ее ошибочно понимают?), а цель - это получение ачивок и поход эффективно оптимизировать такую же, только больше, но другую кантору. Ждать от рантье компетенций в предметной области, чтобы таких руководителей фильтровать на старте и ставить адекватные KPI приходится все реже - такое направление вектора развития - капитал правит, а не интеллект.

Хорошо было бы научиться правильно задавать вопросы, чтобы они содержали половину ответа (с контекстом). Например, вопрос "Какие ещё сервисы есть?" задан неправильно. За это всегда минус сознательно или подсознательно. Этот вопрос должен звучать примерно так "Для того, чтобы мне правильно спроектировать взаимосвязи и не дублировать функции, мне необходимо знать существующий состав сервисов с их кратким описанием. Или давайте действовать в режиме предположений об их наличии или отсутствии, а вы меня поправите". То есть не проявлять пассивную агрессию, заставляя работать коллег с неопределенным конечным результатом, а брать руководство процессом в свои руки. Всегда складывается негативное впечатление о тех, кто не начинает сразу работать, а ждёт на вход всё новую и новую информацию, отсутствие которой ему по неизвестным причинам постоянно мешает.

Я понимаю, что эти вопросы для чек-листа и реально они звучать будут в зависимости от навыка красноречия, но ваши компетенции на собесе показывает именно правильная их формулировка: знание - дело наживное, подход к работе и мотивация - гораздо важнее.

Если не слушать всяких псевдомыслителей-искусствоведов, у которых искусство - это феномен неповторимо личностного творческого мышления, а заимствовать определение искусства в науке, например у археологов, то там предмет искусства - это тот, который не имеет практического значения - фигурки, рисунки и пр. Если ваша программа такая, то поздравляю - вы занимаетесь искусством, а не ремеслом - вы художник, а не инженер.

Это целиком вопрос экономики. Конечно, хотелось бы иметь не только поддержку в новом ядре своей старой "ламповой" архитектуры ЦПУ, но и вообще поддержку старого ядра до бесконечности. Для успешной эволюции от рудиментов надо когда-то избавляться.

О! Наконец-то курс, который подготовит "практиков, способных решать задачи бизнеса"! (нет) Поможет ли такой курс школьнику для поступления в ВУЗ или для обучения в ВУЗе? Конечно же нет. Поможет ли он джуну без высшего образования устроиться на работу? Тоже нет. Какую ПРАКТИЧЕСКУЮ задачу решает курс по подготовке "практиков"?

"современный" - это про гонку. Сначала нужно освоить менее "современные" и занять долю мирового рынка. Если ты производишь только для внутренних нужд втридорога, что возможно только в условиях господдержки, то это не про импортозамещение, не про технологическую независимость и не про другие красивые лозунги, а про распил. Себестоимость снижается только за счет массовости, при которой автоматизация становится выгодной.

Эффективнее всего искать там, где светло. Время - это то, что легче всего оценить. В ИТ это как раз паттерн - предоставить максимально быстро минимально жизнеспособный продукт (MVP). Такой юрист, имхо, у ИТ-шников будет иметь гигантское преимущество перед всей этой не вызывающей никакого доверия братией.

Сама постановка "Почему Agile популярен?" весьма спорна. Корректнее "Почему разговоры про Agile так популярны?". Ведь очень много на самом деле статей не про то как здорово с гибкими подходами, а про то как перестали всех контролировать, забили болт на процессы и документацию и почему-то их спринты не дают результата сами по себе.

Ну и "Как оценить эффективность различных направлений психологии"? По вашим оценкам (и не только) есть два наиболее эффективных направления на три буквы. Ну и как же вы их оценили (и не только)? Статья же об этом или о рекламе именно вашего слова из трех букв?

Ожидал очередную агитацию за SoA с оценкой границы когда это для бизнеса хорошо, а когда плохо, а прочитал маркетинговый буллшит от 1с.

С "маленькой" инфраструктурой бизнес не получит

увеличить стабильность работы,

снизить издержки на команду поддержки

Шина - это неизбежность при попиле монолита и приведении к SoA, а не вот это вот всё с невнятными маркетинговыми рисунками. Для каждой системы есть своя граница эффективности монолита и микросервисов с их ESB, когда появляется выгода от транзакционного контроля и трансформации данных именно в ней, а не при точка-точка. Часто ESB как раз снизит стабильность и увеличит издержки на сопровождение.

В примере конфликта нет конфликта. "Бизнес" хочет обрабатывать только бизнес-информацию и минимизировать издержки, а финансисты хотят BI и статотчетность. Ну это жиза. А вы решаете проблему игнорированием части требований - ампутацией части бизнеса.

"Задачи ставили все, кому не лень " - это в agile называется составлением плана спринта, в котором ДОЛЖНА участвовать вся команда. Задачи берутся не из воздуха - они формируются в результате бизнес-анализа и архитектурной рецензии (пусть для маленьких проектов и в части головы отдельного члена команды) хотелок бизнеса (всего бизнеса, а не разделенного вами на бухгалтеров, финансистов, продажников, производственников и кто там у вас еще). Вы так пишете, как будто это что-то плохое.

Похоже, что вы пытаетесь разрушить Agile-процесс из-за непонимания того, что происходит.

"Чую смердит духом инфоцыганским от вас", сударыня. Вы утверждаете по сути, что успешный успех - это деньги, а важные задачи - это те, которые ведут именно к нему наиболее эффективно. То есть таки да, пытаетесь "выставить неполноценным нищебродом" своего читателя. Иначе никогда бы не написали в выводе "Делать важное дело – это неизбежный стресс". Ведь если мы все таки важность определим хотя бы по Маслоу, а не по инфоцыгански, то увидим, что реализация потребностей в принадлежности и любви (в т.ч. проводить время с ближними), самореализации и уважении (включая передачу знаний, написание инфоцыганских статеек и комментариев к ним) и познание (в т.ч. чтение книг и статей на хабре) - это исключительно важно и далеко не всегда стресс. Берегите себя и учитесь правильно отделять важное для вас и ваших ближних (что то же самое) от важного для чужого дяди или тети-инфоцыгана.

Мне нравится этот шаблон и устоявшийся порядок на 90%! Предположение - мать всех ошибок. Чтобы не ошибаться в 10% случаев (на самом деле, в подавляющем большинстве случаев), не надо предполагать. Совершенно с вами согласен, что название должно отражать суть таблицы. Но имя- это имя. Это якорь после того, как вы узнали что это за таблица на самом деле - чтобы эффективно вспомнить. Может быть это ресторан года в данном городе? Или вообще представленность СЕТЕЙ ресторанов по городам с какого года? Предположений может быть очень много. Необходимо исходить из бизнеса, а не предположений изолированного в подвале DBA. Если в таблице есть ID - это скорее всего вообще синтетический ключ, а не натуральный. И если вы будете использовать именно его, то в большинстве случаев зря потратите ресурсы и время.

Ну, во первых, натуральный ключ - это всегда сущность предметной области. Выбирать необязательный атрибут в качестве ключа - так себе занятие. Номер кузова - это не номер всего автомобиля, а номер его кузова (удивительно, кто бы мог подумать). Для ГАИ это будут одни обязательные атрибуты, для СТО - другие. Например, для СТО - это объект обслуживания - vin автомобиля. При этом надо определить в результате бизнес-анализа vin из документа или vin с автомобиля? Что должно соответствовать чему? Что из этого мастер-данные, а что - производная. Адрес ресторана - это не сущность предметной области ресторанного бизнеса - это предметная сущность почтовой службы. Больше того, в самой постановке "мы создали БД ресторанов и надо выбрать ключ" - критическая ошибка постановки. Чтобы выбрать состав БД нужно сначала понять - зачем? В чем ее бизнес-значение? Что вы хотите от БД с именем ресторана, годом, оценкой и городом? Ваша табличка БД в целом лишена всякого смысла в отрыве от контекста, не только ключ. Может быть вы табличку с объектами в год по городам считаете и вам все равно на имя и rank? Ну тогда ключи "город" и "год" - вполне себе ключи.

Ну и что вы хотели донести своей статьей?

Юристы получили моральное удовлетворение от "выигрыша", стрелочник директор жестоко наказан уголовным штрафом размером аж с зп за несколько дней, а собственник (три штуки в ассортименте) - вообще пострадавший - это же у него убытки, которые пришлось национализировать.

Денег для выплат нет. Ну а откуда они возьмутся, если ГК, по которому не выполнена работа, расторгнут? За счет инвестора что ли? Может быть вы еще предложите рантье работать, разбираться в деятельности компании? Коммунисты что ли? По статье не похоже - те судились бы не в сговоре с инвестором против директора, подсчитывая его квартиру в 60кв.м, а с собственником (всеми тремя) - но тут же вариантов "выиграть" нет - так? "Мы координируем жалобы в прокуратуру", а не добиваемся изменения закона в пользу трудящихся. А потом якобы удивляемся, что "не удалось создать устойчивый коллектив". Зубатовщина как она есть.

Верно подмечено. Математику стоило бы быть внимательнее к формулировкам. Начал за здравие с некорректного заимствования текста (чего llm, в общем, не делает), а закончил за упокой - авторское право на идею. Совсем старик чиновником стал.

Вы забыли про Гражданский кодекс. Оплату за этап почти всегда можно вернуть при ненадлежащем исполнении остальных. Этапность не про это, а про обход авансирования.

Нормальный Заказчик всегда назначает РП со своей стороны, но его функция не непосредственное руководство вашим проектом или даже портфелем проектов, а организация комиссий, экспертиз, архитектурных советов для исправления косяков Исполнителя и комитетов по изменениям для исправления косяков концепций и ТЗ Заказчика (и те и другие всегда есть - без них не бывает) и прочих необходимых мероприятий по приемке работ, включая снятие с Исполнителя статусов для корректного ведения претензионной работы. Ведение же матрицы коммуникаций, управление совещаниями, управление заинтересованными сторонами - это всё процессы Исполнителя. Если он этого не делает, то он не проект реализует, а фрилансит - не создает системный программный продукт, а пишет программку, что на порядок дешевле и не имеет бизнес-ценности.

Вот и вопрос к автору: А где настоящий РП, который ВСЕГДА со стороны Исполнителя? Это по какому фреймворку Исполнитель что-то ждёт от Заказчика не на старте, а уже исполнив 40% работ? По изложенному очевидно, что Исполнитель не умеет как минимум в управление проектом - у него есть контакт и с ФЗ и выход на высшее руководство, но он ждёт, пока вместо него его проектом займется кто-то другой.

Суд ни с кем не судится ни в какой стране. Суд судит. И да, до 22 года можно было в Конституционный суд РТ (на самом деле любой республики РФ, в которой есть своя Конституция) подать заявление о нарушении конституционных прав где угодно в РФ, если по территориальной подсудности вы там проживаете или на территории РТ были нарушены ваши конституционные права. Подать заявление в суд можно на какой угодно орган какой угодно власти в соответствии с правилами подсудности - это не только в РФ - это вообще на планете Земля.

1

Information

Rating
Does not participate
Registered
Activity