Реплика сет описывает сколько подов должно работать одновременно. Реплика сеты позволяют масштабировать количество реплик и... Всё, собственно. Они не поддерживают обновления подов, не то, что определения стратегии их обновления, не поддерживают откаты на предыдущие версии. Так что replica set не развлекается с подами никак. Всё, что она делает - удостоверятся, что количество подов, подходящий под прописанный селектор, равно прописанному и удаляет лишние или поднимает недостающие. С весьма "забавными" побочными эффектами. Это никак не управление подами, это управление количеством подов подходящих под предикат.
Деплоймент же действительно позволяет декларативно разворачивать приложения (состоящие из множества реплика сетов и подов с различными селекторами), определять стратегию обновления, возвращаться к предыдущим версиям и масштабировать количество реплик. Деплоймент является рекомендованной альтернативой для реплик сетов и использует их как внутренний механизм для оркестрации подов (т.е. управления ими).
"Сбежал-ли" ковид из лаборатории или нет - это не имеет к науке никакого отношения. Это политика. И нет никакой "официальной" науки. Есть научные теории (ни одна из которых не отрицает возможность искуственного создания вирусов, кстати) и есть независимые друг от друга организации, занимающиеся научными исследованиями и/или публикациями результатов этих исследований.
Вера в существование "официальной" науке по своей сути, в своём корне - это вера в неких условных "рептилоидов", управляющих всей планетой.
Кстати, наука объясняет, что глаз не был создан "сразу" и прослеживает всю цепочку его эволюции.
P.S. Понятно, что автор сообщения про "скрывают" иронизирует, как и xenon. Просто есть люди, которые верят в наличие "официальной науки" и в то, что факт искуственного происхождения какого-либо вируса опровергает её позицию хоть как-то, автоматически опровергая принципы научных исследований и открывая дорогу всяким теориям заговора и прочему бреду.
Извиняюсь, но с чем из моего поста Вы, собственно, спорите? Я, собственно, и пишу о том, что доверять нейронке проверять свою же нейронковую работу или натравливать другую нейтронку на результаты этой несколько... кхм... опрометчиво. Требуется "ручная" проверка. А проверка осложняется тем, что в отличие от падающего кода, в аналитике ошибку заметить без собственных рассчётов затруднительно. Вы по форме вроде как спорите с моим утверждением, но по сути-то в чём именно суть Вашего несогласия со мной?
Ну и я не знаком с тестами и отделами QA, проверяющими аналитические отчёты. Не поделитесь своими знаниями в этой сфере?
Напомню, задача определить, что аналитика неверная. Допустим, код работающий, но производит неверные данные, на первый взгляд выглядяшие верными. Тесты, написанные той же нейронкой проходятся успешно. Вторая нейтронка не менее успешно производит другой результат (причём тоже неверный), тоже успешно проходя свои же тесты.
Удачи понять без "ручной" проверки логики написаннного, что код неверный до того, как в продакшене пользователи заведут несколько гигабайт неверных данных, по которым пойдёт, допустим, оплата тысяч счетов сотням контрагентов. Точнее, удачи после столь эпичного успеха найти новую работу, видимо.
"Надо", чтобы перейти на новый софт. Это совершенно очевидно из текста, зачем пытаться докопаться до слова там, где его значение очевидно? Сильных аргументов нет?
Я употребил слово "активность" как синоним слова "результат". Вот это не очевидно и это болевая точка множества сотрудников, согласен. Тут мне следовало бы быть аккуратнее со словами.
Значит, ваш софт, на котором вы с коллегами сидите сейчас, не менее глючный. Следовательно, эта жалоба нерелевантна.
Вы совершенно правы, в свои 43 года из которых уже 21 год я вращаюсь в IT на должностях от рядового сотрудника до старшего руководителя, я никогда не переходил на новое ПО, не участвовал во внедрениях, в переходах, принятии решений как о переходах, так и о не переходах на новое ПО или новую версию существующего ПО, в создании ПО как внутреннего, так и продукта. Ой, нет. Я всё это делал и делаю.
Возможно, это Вы пытаетесь спорить с тем, кто ел и устриц и раков и бог знает что ещё и видит картину с разных перспектив. За всю свою карьеру я помню только один продукт, который нам пытались продать, но который был глючен до неработоспособности. Какая-то российская система документооборота лет 15, наверное, назад. И, внезано, её не стали покупать и внедрять.
Это далеко не самая главная причина. Это самая частая отмазка. Если копнуть глубже, и начать разбираться, почему же новый софт "дерьмо", в большинстве случаев окажется, что он непривычный, надо изучать, надо ломать сложившиеся привычки, лучше показывает активность сотрудника... И в крайне редких случаях он действительно глючный или даже неработающий. Такое тоже бывает, но отнюдь не настолько часто, чтобы быть "самым главным".
Ну, давайте разберем. Академическое, так академическое. Чтобы это ни значило.
Во-первых, оговорим, что любые определения Котлера ограничены сферой маркетинга, который по Котлеру "is the process by which companies create value for customers and build strong customer relationships in order to capture value from customers in return". Т.е. отношения компании и её клиентов в рамках рыночных отношений обмена ценностями (market - ing).
Во-вторых, Котлер не определяет продукт как "всё, что удовлетворяет потребность пользователя". По его определению (раздел G1 Glossary в конце книги) "Product - Anything that can be offered to a market for attention, acquisition, use, or consumption that might satisfy a want or need". Другими словами, Котлер вторит мне, точнее, я ему вторю, утверждая, что продукт - это нечто для рынка, а не для внутреннего потребления.
Хм... Я вижу очередная попытку подмены. В этот раз это подмена обсуждаемой темы. Где я написал, что для внутренней разработки не нужно некое звено между пользователем и разработчиком? Правильно - нигде.
Я говорю, что не надо называть внутреннюю разработку тем, чем она не является - продуктом, чем-то, что предназначено для рынка, для продажи множеству клиентов. Она ровно противоположена в своём определении - она предназначена для решения конкретных задач одного заказчика в жестких рамках его экосистемы. И тогда куда проще становится объяснить, что какие-то роли хоть и имеют схожие цели, методы у них будут различаться.
Обзовите эту роль более правильно. Например, Solution Owner. При всех возможных недостатках использования слова 'solution', по крайней мере, оно не меняет значение слова на противоположенное добавлением прилагательного и описывает ровно то, что под ним подразумевается, пусть и несколько широко. И люди будут понимать, что требования к этой роли чем-то отличаются от Product Owner и нельзя бездумно переносить навыки одной роли на другую.
Если называть вещи своими именами, то исчезает много проблем.
Продукт предназначен для рынка. А внутренняя разработка - это внутренняя разработка, но никак не продукт. Поэтому и подход требуется совершенно другой, собственно.
Прежде всего, небольшое замечание. Live coding - "живое" кодирование, кодирование в прямом эфире, не life coding - кодирование жизни.
Взгляд со стороны технаря - создателя продукта.
Упражнение - создание наброска дизайна под очень конкретный сценарий за ограниченное время. Цель упражнения - продемонстрировать свой подход к решению подобных задач наравне с умением оставаться в рамках обсуждаемой темы.
Важно - не надо пытаться показать своё глобальное видение, обширные знания и всё такое прочее. Это всё прошли на этапе собеседования. Надо попытаться решить конкретную задачу. При этом показать умение учитывать желание заказчика, разумеется.
Как бы я подошёл к решению конкретной задачи.
1 Понимание задачи через вопросы. а) Выявление отличий от тех бизнес-процессов которые вы понимаете, либо имеете о них общее представление. Как вариант, т.к. тест синтетический, можно выдвинуть встречный синтетический сценарий.
Допустим, что обычные курьеры (простите, представители) работают так-то и так-то. Хоть что-то решающее такую задачу вообразить должен любой дизайнер. Пусть в реальности они вообще не так работают, это не важно для данного теста.
В чём значительное для решения задачи отличие роверов от представителей? Мне не нужно понимание, как роверы двигаются по маршруту или как конкретно с точки технической реализации туда карта загружается и как именно она выгружается. Мне нужно понимание, нужна ли им подзарядка в течение дня и, например, осмотр после каждого клиента, т.к. это важные шаги бизнес-процесса. Что собеседующий перечислил - то и важно. Что забыл - того не существует.
Нельзя самому выдвигать какие-то предположения, если нет понимания хоть чего-то похожего - мы просто записываем шаг за шагом все основные переходы между участниками процесса, избегая впадания в подробности. Нужно задавать вопросы. Итак, начинаем с того, что клиент заказал карту, то дальше? ОК, дальше карту изготовили и доставили в распределительный пункт. Что дальше? Дальше карту загрузили в ровер и он повёз её до места. Дальше? Дальше дошёл ровер до места и послал СМС клиенту. Дальше? Дальше клиент ПИН-код ввёл и получил карту. Стоп, откуда у него ПИН-код? Он получил его на указанный способ связи после оформления заявки и изготовления карты. ОК, т.е. шаг №3 - отправление клиенту ПИН-кода. Карта получена, что дальше? Дальше ровер отправляется по маршруту. А когда маршрут закончен? Дальше ровер идёт на быстрый осмотр, потом зарядка, потом новая загрузка. ОК. А клиент? А клиент дальше как обычно, это уже всё есть. ОК, закончили тогда. Получается вот это - согласны? Где неточности? Что пропущено? Ничего? ОК.
Всё, значит роверы у нас не застревают, не ломаются, нет шагов с этим связанных в нашем мире. Если что-то упущенное пришло в голову самим - можно упомянуть просто как что-то, что мы сейчас рассматривать не будем, чтобы показать, что у вас самих есть какое-то представление - это плюсов добавит, но если не пришло в голову, то и фиг с ним. И так хорошо.
Это просто пример - я не имею представления как эти ваши роверы работают, у нас в Австралиях их нет пока что.
Пусть включают своё воображение тоже, пусть участвуют в процессе по полной - ваша задача показать умение получения информации из третьих лиц, а не способность телепатии. А ешё ваша задача уметь показать способность концентрироваться на важном и отбрасывать второстепенное.
б) Выявление жёстких ограничений, которые прямо не указаны пока что в шагах БП, но важны с точки зрения UX. Требования закона, например. Или неспособность открыть дверь и подняться по лестнице. Что не перечисленно клиентом - того не существует в нашем синтетическом мире этой задачи.
Цель этого этапа - выстроить каркас из:
а) основных шагов бизнес-процесса, диктуемых как жёсткими ограничениями, которые нельзя обойти, так и сложившимися в компании привычными процессами.
б) в случае принципиального непонимания процесса или слишком большой сложности задачи, создания искусственного упрощённого сценария для укладывания в заданные временные рамки. Это синтетический тест, так примите участие в задании ограничений для облегчения его выполнения.
Результат - искуственный бизнес-процесс содержащий все важные для решения задачи шаги и ваше понимание всего этого. Никаких метрик, никаких целей. Просто как это делается с точки зрения клиента и каковы важные ограничения на этом всём лежат.
2 Теперь у нас есть понимание процесса, можно выдвигать гипотезы, строить прототипы. Вот тут уже могут быть важны задачи бизнеса - хотят ли они сделать роверы основным средством доставки или это просто опция для определённых сценариев (доставка поздно вечером, как вариант). Вот на этом этапе эти вопросы продемонстрируют Вашу способность строить гипотезы, удовлетворяющие запросам и модифицировать решение под эти запросы.
Никаких вопросов про метрики. Метрики ВТОРИЧНЫ. Задачи бизнеса ПЕРВИЧНЫ. На вторичное в условиях жётского ограничения нет времени. Тут выявится почти наверняка что-то, пропущенное на первом этапе. Например, этап выбора даты и времени доставки карты.
Ну и как технарь, дальше я идти не буду, это вам дизайнерам виднее и привычнее. Я дальше сделаю наброски дизайна экранов, UX flows, wire flows если можно таким гордым словом описать мои каракули и т.д. Но я не дизайнер, я технарь - решатель проблем. Я описал свой обычный подход к поиску решения реальных практических задач, которые я изначально не понимаю. Для меня он работает и примерно так я бы подошёл к такому тестированию.
Коротко: 1 Через вопросы сформировать понимание процесса как такового на этапах передачи информации/задач между участниками процесса. Определить жёсткие ограничения процесса на каждом шаге. В случае полного непонимания задачи, сформулировать синтетическое решение по аналогии на своих представлениях. Это наш "контракт" с заказчиком. SoW, ТЗ, требования. You name it.
Это те самые 10 минут "вопрос-ответ". Вряд-ли уложитесь, если нет никакого понимания, пусть 20 будет. Гипотеза всё равно формируется во многом уже здесь, т.к. дальше работать будете просто отражая шаги БП в UX.
2 Сформировав представление о задаче решить её, уточняя пожелания и требования заказчика в рамках "контракта" на этом этапе, отсекая, однако, всё большое, что не вошло в понимание процесса, если только это не критически важно для заказчика, т.к. время ограничено. Умение оставаться в рамках задачи, а не растекаться - это крайне важное умение, которое полезно продемонстрировать. Можно вернуться к новым требованиям, если время останется. Или, как вариант, продолжить его обсуждения здесь и сейчас если заказчики готовы добавить время для обсуждения этого тоже, или если они готовы признать успехом что-то не готовое по истечению времени.
Это шаги формирования гипотезы и прототипа. 20-30 минут. Или больше.
Так в том-то и дело, что это ни разу не "чуйка", которую руками не потрогать и не передать другим в виде знания. Это набор методов и навыков, которые вполне себе формализуются и передаются через обучение.
А чем отличается "так себе цель" в виде "внедрим CRM" или "давайте забубеним классную новую фишку" от отсутствия цели? ИМХО, только тем, что кто-то по глупости может на неё бюджет выделить, т.е. это может принести даже больше вреда, чем полное отсутствие цели, т.к. в случае отсутствия цели хотя бы бюджет останется.
Сейчас с этим GenAI все носятся и утверждают, что клиенты не купят никакого решения, если в нём нет слов GenAI. По крайней мере в стране, в которой я сейчас работаю. С точки зрения исполнителя - ОК, попил бюджета на хайповой теме, заказчик-барин. Но заказчикам бы не мешало подумать, а в чём их польза будет в конкретных цифрах. ИМХО, хороший пример "так себе цели", требующей больших ресурсов, но далеко не всегда способной хоть как-то себя окупить.
Очевидно же, что цель статьи в перечислении ошибок, а не в подробном описании того, как их избежать. И в этом отношении статья вполне хороша, а других задач в ней не наблюдается. Конкретно по целям и метрикам - это даже не статья, а серия статей или книга получится, чтобы раскрыть как же их готовить. Впрочем, тут по каждому пункту понадобится своя большая статья, чтобы хоть как-то раскрыть тему.
Но если вкратце, то "а давайте новую классную CRM внедрим, как-то с клиентами отношения не очень" - это цель фиговая, но как стартовая точка обсуждения пойдёт. Через обсуждение того, что же конкретно значит "с клиентами отношения не очень", можно выйти и на чёткость формулировки и на измеримость показателя.
Например, отношения фиговые, т.к. много клиентов не собираются продлевать контракт на следующий год. А "много" это сколько конкретно? 30 процентов. А сколько нормально? Обычно 10-15% было. Вот тебе конкретная измеримая цель. Как будем достигать, давайте думать, что может изменить ситуацию и как это повлияет на другие показатели компании, прежде всего финансовые (главная задача бизнеса - извлечение прибыли, не стоит об этом забывать). Может, дело не в CRM вообще?
Или количество заявок с негативным сентиментом (прошу прощения, в последние годы я работаю зарубежом и несколько забываю русскую терминологию) растёт. Но если покопаться, то растёт оно прежде всего в связи с обшим ростом количества клиентов и практически не сказывается на других показателях. Люди ругаются, но продолжают пользоваться и платить, поэтому проблема не критичная и бросать все ресурсы на её решение может быть неразумно.
В общем, стоит только задаться целью перейти от общих слов к конкретному описанию конкретных проблем, а там уже на измеримые показатели выйти можно. Не всегда легко, но никто не обещал, что будет легко.
Так что, нет, мы не хотим просто взять бумажку и что-то туда формально записать, мы действительно хотим понять проблемы бизнеса. А это как раз и означает переход от общих слов к конкретным проблемам и связанным с ними метриками. Бизнес в целом управляется по метрикам, поэтому это в любом случае полезно.
Любой член команды может внести новый термин в проект. Главное, в случае обнаружения расхождений в понимании, зафиксировать это расхождение, устранить его и внести термин и его определение в условный "словарь". А можно и не в условный, а в соответствующий документ.
А стоит ли начинать новый проект без чёткой измеримой цели? Если нет чёткого понимания, для чего это всё делается, и способа измерить, в правильном ли направлении дело движется, то проект де-факто делается исключительно для попила бюджета. И даже в этом случае, можно сам факт попила сделать целью. Чёткой и измеримой, пусть и неформальной/скрытой от заказчика. "Попилить N миллионов рублей командой из X человек за T месяцев".
На самом деле многое лежит на умении грамотно составить SoW (ТЗ), управлять доступными ресурсами и работать с изменениями, точнее запросами на изменения. Что гораздо более чётко формализуемо, чем "чуйка".
Очевидные риски известны. На них натыкались многие уже много-много раз. Предусмотреть и закрыть или принять их можно. Всё не предусмотришь, но многое - вполне.
Это очень разные понятия.
Примерно там, где находится понимание отличий управления от общения. Свобода принятия решений в способах выполнения поставленной задачи (причем, задача может быть поставлена крайне широко) совершенно ортогональна неправильному пониманию поставленной задачи, отсутствию своевременных отчётов о статусе задачи, или возникших препятствиях в её решении. Она даже отличается от разрешения/приказа начать выполнять задачу после принятия решения о том, как её выполнять. Советую книгу "Turn the ship around!" - она как раз про это, на самом деле. Или в основном про это.
Управление изменениями - это не только и даже не столько про OKR (я надеюсь, Вы же не KPI имели в виду под измеримыми показателями?). Подавляющее большинство изменений не затрагивают OKR, но затрагивают методы их достижения.
Документирование ничем не важнее понимания целей проекта и его содержания внутри команды, грамотного планирования и менеджмента. Внутри маленькой команды, делающей небольшой проект, вполне можно достичь успеха без хорошей внутренней документации. Но вот формальное документирование без понимания, планирования и управления разве что и сможет, что с какой-то степенью успешности прикрыть зад менеджера, да и то без гарантий. Ибо провал проекта, даже грамотно прикрытый документацией, редко становится плюсом в репутацию управленца. Документирование хорошо как метод достижения пунктов 1-7, если выполняется грамотно.
Я сужу не по себе, а по опыту управления людьми и по той информации, что я изучил, чтобы хоть как-то ими управлять. И выводы я сделал, исходя из Ваших слов, а не моих.
Давайте в последний раз разберём Ваши слова. "Это для него значительный опыт для будущих работ".
Это Ваше понимание его мотивации. Либо ваша мотивация для него, то, что Вы лично ему подаёте. В любом случае эта мотивация предполагает уход данного человека после получения опыта. Куда? На "будущие работы". Не Ваш стартап.
Возникает вопрос. Это риск для стартапа - потерять ключевого сотрудника (а один из двух сотрудников в любом случае ключевой)? Риск. Всё. Надо этот риск просто признать и с ним работать. Как? Решайте сами. Я был лично убрал такую мотивацию и выбрал мотивацию, неразрывно связанную с успехом Вашего предприятия, оставив "будущие работы" в стороне. Причём, раз уж между учёбой и работой он выбрал учёбу, его обеспечивает кто-то ещё (родители), а не он сам. Следовательно, финансы его не интересуют сегодня. Это тоже надо учитывать при мотивировании.
Вы же, по ощущениям от Ваших слов, просто игнорируете этот риск. Ну какое отношение Ваш стартап имеет к конфликту между учёбой и работой? Да никакого. Поэтому неудивительно, что Вас он оставил как есть - Вы не мешали ни учёбе, ни работе. Но Вы используете этот конфликт как оправдание отсутствия риска для Вас. А на самом деле, это дополнительный риск. Что если Ваше предприятие начнёт мешать учёбе? Что он выберет? Вы знаете ответ на этот вопрос, обсудили с ним это?
Кроме того, не могу не заметить, что Вы, в отличие от меня, взяли на себя смелость судить обо мне исходя не из моих слов, а исходя либо из личной обиды, либо, как раз, судя по себе. Вы не знаете обо мне и моей мотивации ровным счётом ничего.
И по своему опыту работы в стартапе, ради которого я переехал за 10К+ км на весьма изначально скромную з.п., потеряв для своей семьи очень сильно в качестве жизни на несколько лет, работая буквально за еду и жильё, я могу сказать, что очень важно, крайне важно сотруднику понимать чётко, что его ожидает в случае успеха и в случае провала. И в чём конкретно измеряется успех или провал.
И не надо полагать, что сотрудник умеет читать Ваши мысли. Нужен прямой разговор об этом с расставлением всех точек над i. Просто "разделим 50/50" недостаточно, т.к. под этим каждый понимает что-то своё и это никак не отражает того, кто какую роль будет в будущем играть. Кромет того, часто не получается сохранить 50/50, т.к. обычно появляются миноритарные совладельцы, размывая доли владения.
Мне не нужно знать ни о чём Ваш продукт ни где находятся Ваши клиенты, чтобы видеть, что мотивация разработчика "наберусь опыта, чтобы работать где-то ещё" рискована для Вас лично. На что именно он при этом согласился - дело вторичное, если не десятое. С такой мотивацией он уйдёт сразу же, как только получит хороший оффер. Про создание клона я не писал ничего.
Я вижу два огромных риска в Вашем комментарии. 1. Сам разработчик. Почему оплатой вашего "CTO" является "значительный опыт для будущих работ"? Каких таких "будущих работ"? Он собирается использовать Ваш стартап как стартовую площадку для "корпоративной" карьеры? Тогда Вы лично в огромной беде - Вы запрограмированы на то, что лишитесь единственного человека, который досконально знает Ваш продукт с технической стороны. У вас есть, хотя бы, юрлицо и контрактные обязательства между вами обоими и этим юрлицом? Доли расписаны юридически, или всё на словах? 2. Ваш друг. Вы используете своего друга как ментора для обучения неопытного разработчика, который хочет уйти как только наберётся опыта. Что, если Вашему другу надоест?
В сумме по Вашему описанию, Вы завязаны на двух людей, не особо замотивированных в том, чтобы Ваш стартап развивался. Один менторит ради собственного интереса, другой разрабатывает ради опыта.
Ну и не надо обманываться, никакой ответственности никто из вас не берёт. Любой из вас может отвалиться в любой момент и не понесёт никаких потерь. Ни финансовых, ни репутационных. Вы вкладываете своё время, но и в хобби люди вкладывают время и даже деньги и никому в голову не приходит называть занятие хобби ответственностью.
Не поймите меня неправильно, я желаю Вам и Вашей команде успеха. Более того, я сам ни шатко не вяло занимаюсь своим личным стартапом в свободное от работы время. Но это не бизнес подход, это хобби. Основная моя работа - как раз "СТО" стартапа, проданного большой компании.
До тех пор, пока вы или я не начнём вкладывать деньги или финансовые обязательства в какой-то форме (инвестиции, деньги клиентов в обмен на обещание услуги или товара, деловую репутацию) в предпринимательскую деятельность, осуществляя это на свой страх и риск, мы оба занимаемся хобби, а не предпринимательством/бизнесом (кстати, в английском это связанные, но разные понятия).
Интересный опыт, из которого думающий человек может сделать множество полезных для себя выводов. Зря минусуете. Хотелось бы увидеть картину и с другой стороны, но и так можно многое увидеть и использовать, если хотите поучаствовать в стартапа в роли CTO.
CSS - customer support services, не листы каскадных стилей.
Уволили не айтишников, а сотрудников службы поддержки.
Асболютно верное описание.
Реплика сет описывает сколько подов должно работать одновременно. Реплика сеты позволяют масштабировать количество реплик и... Всё, собственно. Они не поддерживают обновления подов, не то, что определения стратегии их обновления, не поддерживают откаты на предыдущие версии. Так что replica set не развлекается с подами никак. Всё, что она делает - удостоверятся, что количество подов, подходящий под прописанный селектор, равно прописанному и удаляет лишние или поднимает недостающие. С весьма "забавными" побочными эффектами. Это никак не управление подами, это управление количеством подов подходящих под предикат.
Деплоймент же действительно позволяет декларативно разворачивать приложения (состоящие из множества реплика сетов и подов с различными селекторами), определять стратегию обновления, возвращаться к предыдущим версиям и масштабировать количество реплик. Деплоймент является рекомендованной альтернативой для реплик сетов и использует их как внутренний механизм для оркестрации подов (т.е. управления ими).
"Сбежал-ли" ковид из лаборатории или нет - это не имеет к науке никакого отношения. Это политика. И нет никакой "официальной" науки. Есть научные теории (ни одна из которых не отрицает возможность искуственного создания вирусов, кстати) и есть независимые друг от друга организации, занимающиеся научными исследованиями и/или публикациями результатов этих исследований.
Вера в существование "официальной" науке по своей сути, в своём корне - это вера в неких условных "рептилоидов", управляющих всей планетой.
Кстати, наука объясняет, что глаз не был создан "сразу" и прослеживает всю цепочку его эволюции.
P.S. Понятно, что автор сообщения про "скрывают" иронизирует, как и xenon. Просто есть люди, которые верят в наличие "официальной науки" и в то, что факт искуственного происхождения какого-либо вируса опровергает её позицию хоть как-то, автоматически опровергая принципы научных исследований и открывая дорогу всяким теориям заговора и прочему бреду.
Извиняюсь, но с чем из моего поста Вы, собственно, спорите? Я, собственно, и пишу о том, что доверять нейронке проверять свою же нейронковую работу или натравливать другую нейтронку на результаты этой несколько... кхм... опрометчиво. Требуется "ручная" проверка. А проверка осложняется тем, что в отличие от падающего кода, в аналитике ошибку заметить без собственных рассчётов затруднительно. Вы по форме вроде как спорите с моим утверждением, но по сути-то в чём именно суть Вашего несогласия со мной?
Ну и я не знаком с тестами и отделами QA, проверяющими аналитические отчёты. Не поделитесь своими знаниями в этой сфере?
"Неработающий код" - отлично...
Напомню, задача определить, что аналитика неверная. Допустим, код работающий, но производит неверные данные, на первый взгляд выглядяшие верными. Тесты, написанные той же нейронкой проходятся успешно. Вторая нейтронка не менее успешно производит другой результат (причём тоже неверный), тоже успешно проходя свои же тесты.
Удачи понять без "ручной" проверки логики написаннного, что код неверный до того, как в продакшене пользователи заведут несколько гигабайт неверных данных, по которым пойдёт, допустим, оплата тысяч счетов сотням контрагентов. Точнее, удачи после столь эпичного успеха найти новую работу, видимо.
"Надо", чтобы перейти на новый софт. Это совершенно очевидно из текста, зачем пытаться докопаться до слова там, где его значение очевидно? Сильных аргументов нет?
Я употребил слово "активность" как синоним слова "результат". Вот это не очевидно и это болевая точка множества сотрудников, согласен. Тут мне следовало бы быть аккуратнее со словами.
Значит, ваш софт, на котором вы с коллегами сидите сейчас, не менее глючный. Следовательно, эта жалоба нерелевантна.
Вы совершенно правы, в свои 43 года из которых уже 21 год я вращаюсь в IT на должностях от рядового сотрудника до старшего руководителя, я никогда не переходил на новое ПО, не участвовал во внедрениях, в переходах, принятии решений как о переходах, так и о не переходах на новое ПО или новую версию существующего ПО, в создании ПО как внутреннего, так и продукта. Ой, нет. Я всё это делал и делаю.
Возможно, это Вы пытаетесь спорить с тем, кто ел и устриц и раков и бог знает что ещё и видит картину с разных перспектив. За всю свою карьеру я помню только один продукт, который нам пытались продать, но который был глючен до неработоспособности. Какая-то российская система документооборота лет 15, наверное, назад. И, внезано, её не стали покупать и внедрять.
Это далеко не самая главная причина. Это самая частая отмазка.
Если копнуть глубже, и начать разбираться, почему же новый софт "дерьмо", в большинстве случаев окажется, что он непривычный, надо изучать, надо ломать сложившиеся привычки, лучше показывает активность сотрудника... И в крайне редких случаях он действительно глючный или даже неработающий. Такое тоже бывает, но отнюдь не настолько часто, чтобы быть "самым главным".
Ну, давайте разберем. Академическое, так академическое. Чтобы это ни значило.
Во-первых, оговорим, что любые определения Котлера ограничены сферой маркетинга, который по Котлеру "is the process by which companies create value for customers and build strong customer relationships in order to capture value from customers in return". Т.е. отношения компании и её клиентов в рамках рыночных отношений обмена ценностями (market - ing).
Во-вторых, Котлер не определяет продукт как "всё, что удовлетворяет потребность пользователя". По его определению (раздел G1 Glossary в конце книги) "Product - Anything that can be offered to a market for attention, acquisition, use, or consumption that might satisfy a want or need". Другими словами, Котлер вторит мне, точнее, я ему вторю, утверждая, что продукт - это нечто для рынка, а не для внутреннего потребления.
Хм... Я вижу очередная попытку подмены. В этот раз это подмена обсуждаемой темы. Где я написал, что для внутренней разработки не нужно некое звено между пользователем и разработчиком? Правильно - нигде.
Я говорю, что не надо называть внутреннюю разработку тем, чем она не является - продуктом, чем-то, что предназначено для рынка, для продажи множеству клиентов. Она ровно противоположена в своём определении - она предназначена для решения конкретных задач одного заказчика в жестких рамках его экосистемы. И тогда куда проще становится объяснить, что какие-то роли хоть и имеют схожие цели, методы у них будут различаться.
Обзовите эту роль более правильно. Например, Solution Owner. При всех возможных недостатках использования слова 'solution', по крайней мере, оно не меняет значение слова на противоположенное добавлением прилагательного и описывает ровно то, что под ним подразумевается, пусть и несколько широко. И люди будут понимать, что требования к этой роли чем-то отличаются от Product Owner и нельзя бездумно переносить навыки одной роли на другую.
Если называть вещи своими именами, то исчезает много проблем.
Продукт предназначен для рынка. А внутренняя разработка - это внутренняя разработка, но никак не продукт. Поэтому и подход требуется совершенно другой, собственно.
Прежде всего, небольшое замечание. Live coding - "живое" кодирование, кодирование в прямом эфире, не life coding - кодирование жизни.
Взгляд со стороны технаря - создателя продукта.
Упражнение - создание наброска дизайна под очень конкретный сценарий за ограниченное время. Цель упражнения - продемонстрировать свой подход к решению подобных задач наравне с умением оставаться в рамках обсуждаемой темы.
Важно - не надо пытаться показать своё глобальное видение, обширные знания и всё такое прочее. Это всё прошли на этапе собеседования. Надо попытаться решить конкретную задачу. При этом показать умение учитывать желание заказчика, разумеется.
Как бы я подошёл к решению конкретной задачи.
1 Понимание задачи через вопросы.
а) Выявление отличий от тех бизнес-процессов которые вы понимаете, либо имеете о них общее представление. Как вариант, т.к. тест синтетический, можно выдвинуть встречный синтетический сценарий.
Допустим, что обычные курьеры (простите, представители) работают так-то и так-то. Хоть что-то решающее такую задачу вообразить должен любой дизайнер. Пусть в реальности они вообще не так работают, это не важно для данного теста.
В чём значительное для решения задачи отличие роверов от представителей? Мне не нужно понимание, как роверы двигаются по маршруту или как конкретно с точки технической реализации туда карта загружается и как именно она выгружается. Мне нужно понимание, нужна ли им подзарядка в течение дня и, например, осмотр после каждого клиента, т.к. это важные шаги бизнес-процесса. Что собеседующий перечислил - то и важно. Что забыл - того не существует.
Нельзя самому выдвигать какие-то предположения, если нет понимания хоть чего-то похожего - мы просто записываем шаг за шагом все основные переходы между участниками процесса, избегая впадания в подробности. Нужно задавать вопросы. Итак, начинаем с того, что клиент заказал карту, то дальше? ОК, дальше карту изготовили и доставили в распределительный пункт. Что дальше? Дальше карту загрузили в ровер и он повёз её до места. Дальше? Дальше дошёл ровер до места и послал СМС клиенту. Дальше? Дальше клиент ПИН-код ввёл и получил карту. Стоп, откуда у него ПИН-код? Он получил его на указанный способ связи после оформления заявки и изготовления карты. ОК, т.е. шаг №3 - отправление клиенту ПИН-кода. Карта получена, что дальше? Дальше ровер отправляется по маршруту. А когда маршрут закончен? Дальше ровер идёт на быстрый осмотр, потом зарядка, потом новая загрузка. ОК. А клиент? А клиент дальше как обычно, это уже всё есть. ОК, закончили тогда. Получается вот это - согласны? Где неточности? Что пропущено? Ничего? ОК.
Всё, значит роверы у нас не застревают, не ломаются, нет шагов с этим связанных в нашем мире. Если что-то упущенное пришло в голову самим - можно упомянуть просто как что-то, что мы сейчас рассматривать не будем, чтобы показать, что у вас самих есть какое-то представление - это плюсов добавит, но если не пришло в голову, то и фиг с ним. И так хорошо.
Это просто пример - я не имею представления как эти ваши роверы работают, у нас в Австралиях их нет пока что.
Пусть включают своё воображение тоже, пусть участвуют в процессе по полной - ваша задача показать умение получения информации из третьих лиц, а не способность телепатии. А ешё ваша задача уметь показать способность концентрироваться на важном и отбрасывать второстепенное.
б) Выявление жёстких ограничений, которые прямо не указаны пока что в шагах БП, но важны с точки зрения UX. Требования закона, например. Или неспособность открыть дверь и подняться по лестнице. Что не перечисленно клиентом - того не существует в нашем синтетическом мире этой задачи.
Цель этого этапа - выстроить каркас из:
а) основных шагов бизнес-процесса, диктуемых как жёсткими ограничениями, которые нельзя обойти, так и сложившимися в компании привычными процессами.
б) в случае принципиального непонимания процесса или слишком большой сложности задачи, создания искусственного упрощённого сценария для укладывания в заданные временные рамки. Это синтетический тест, так примите участие в задании ограничений для облегчения его выполнения.
Результат - искуственный бизнес-процесс содержащий все важные для решения задачи шаги и ваше понимание всего этого. Никаких метрик, никаких целей. Просто как это делается с точки зрения клиента и каковы важные ограничения на этом всём лежат.
2 Теперь у нас есть понимание процесса, можно выдвигать гипотезы, строить прототипы. Вот тут уже могут быть важны задачи бизнеса - хотят ли они сделать роверы основным средством доставки или это просто опция для определённых сценариев (доставка поздно вечером, как вариант). Вот на этом этапе эти вопросы продемонстрируют Вашу способность строить гипотезы, удовлетворяющие запросам и модифицировать решение под эти запросы.
Никаких вопросов про метрики. Метрики ВТОРИЧНЫ. Задачи бизнеса ПЕРВИЧНЫ. На вторичное в условиях жётского ограничения нет времени. Тут выявится почти наверняка что-то, пропущенное на первом этапе. Например, этап выбора даты и времени доставки карты.
Ну и как технарь, дальше я идти не буду, это вам дизайнерам виднее и привычнее. Я дальше сделаю наброски дизайна экранов, UX flows, wire flows если можно таким гордым словом описать мои каракули и т.д. Но я не дизайнер, я технарь - решатель проблем. Я описал свой обычный подход к поиску решения реальных практических задач, которые я изначально не понимаю. Для меня он работает и примерно так я бы подошёл к такому тестированию.
Коротко:
1 Через вопросы сформировать понимание процесса как такового на этапах передачи информации/задач между участниками процесса. Определить жёсткие ограничения процесса на каждом шаге. В случае полного непонимания задачи, сформулировать синтетическое решение по аналогии на своих представлениях. Это наш "контракт" с заказчиком. SoW, ТЗ, требования. You name it.
Это те самые 10 минут "вопрос-ответ". Вряд-ли уложитесь, если нет никакого понимания, пусть 20 будет. Гипотеза всё равно формируется во многом уже здесь, т.к. дальше работать будете просто отражая шаги БП в UX.
2 Сформировав представление о задаче решить её, уточняя пожелания и требования заказчика в рамках "контракта" на этом этапе, отсекая, однако, всё большое, что не вошло в понимание процесса, если только это не критически важно для заказчика, т.к. время ограничено.
Умение оставаться в рамках задачи, а не растекаться - это крайне важное умение, которое полезно продемонстрировать. Можно вернуться к новым требованиям, если время останется. Или, как вариант, продолжить его обсуждения здесь и сейчас если заказчики готовы добавить время для обсуждения этого тоже, или если они готовы признать успехом что-то не готовое по истечению времени.
Это шаги формирования гипотезы и прототипа. 20-30 минут. Или больше.
DCS бесплатен. Платны модули, т.е. самолёты, вертолеты, и карты. И вот их можно протестировать бесплатно на две недели каждые шесть месяцев.
Так в том-то и дело, что это ни разу не "чуйка", которую руками не потрогать и не передать другим в виде знания. Это набор методов и навыков, которые вполне себе формализуются и передаются через обучение.
А чем отличается "так себе цель" в виде "внедрим CRM" или "давайте забубеним классную новую фишку" от отсутствия цели? ИМХО, только тем, что кто-то по глупости может на неё бюджет выделить, т.е. это может принести даже больше вреда, чем полное отсутствие цели, т.к. в случае отсутствия цели хотя бы бюджет останется.
Сейчас с этим GenAI все носятся и утверждают, что клиенты не купят никакого решения, если в нём нет слов GenAI. По крайней мере в стране, в которой я сейчас работаю. С точки зрения исполнителя - ОК, попил бюджета на хайповой теме, заказчик-барин. Но заказчикам бы не мешало подумать, а в чём их польза будет в конкретных цифрах. ИМХО, хороший пример "так себе цели", требующей больших ресурсов, но далеко не всегда способной хоть как-то себя окупить.
Очевидно же, что цель статьи в перечислении ошибок, а не в подробном описании того, как их избежать. И в этом отношении статья вполне хороша, а других задач в ней не наблюдается. Конкретно по целям и метрикам - это даже не статья, а серия статей или книга получится, чтобы раскрыть как же их готовить. Впрочем, тут по каждому пункту понадобится своя большая статья, чтобы хоть как-то раскрыть тему.
Но если вкратце, то "а давайте новую классную CRM внедрим, как-то с клиентами отношения не очень" - это цель фиговая, но как стартовая точка обсуждения пойдёт. Через обсуждение того, что же конкретно значит "с клиентами отношения не очень", можно выйти и на чёткость формулировки и на измеримость показателя.
Например, отношения фиговые, т.к. много клиентов не собираются продлевать контракт на следующий год. А "много" это сколько конкретно? 30 процентов. А сколько нормально? Обычно 10-15% было. Вот тебе конкретная измеримая цель. Как будем достигать, давайте думать, что может изменить ситуацию и как это повлияет на другие показатели компании, прежде всего финансовые (главная задача бизнеса - извлечение прибыли, не стоит об этом забывать). Может, дело не в CRM вообще?
Или количество заявок с негативным сентиментом (прошу прощения, в последние годы я работаю зарубежом и несколько забываю русскую терминологию) растёт. Но если покопаться, то растёт оно прежде всего в связи с обшим ростом количества клиентов и практически не сказывается на других показателях. Люди ругаются, но продолжают пользоваться и платить, поэтому проблема не критичная и бросать все ресурсы на её решение может быть неразумно.
В общем, стоит только задаться целью перейти от общих слов к конкретному описанию конкретных проблем, а там уже на измеримые показатели выйти можно. Не всегда легко, но никто не обещал, что будет легко.
Так что, нет, мы не хотим просто взять бумажку и что-то туда формально записать, мы действительно хотим понять проблемы бизнеса. А это как раз и означает переход от общих слов к конкретным проблемам и связанным с ними метриками. Бизнес в целом управляется по метрикам, поэтому это в любом случае полезно.
Любой член команды может внести новый термин в проект. Главное, в случае обнаружения расхождений в понимании, зафиксировать это расхождение, устранить его и внести термин и его определение в условный "словарь". А можно и не в условный, а в соответствующий документ.
А стоит ли начинать новый проект без чёткой измеримой цели? Если нет чёткого понимания, для чего это всё делается, и способа измерить, в правильном ли направлении дело движется, то проект де-факто делается исключительно для попила бюджета. И даже в этом случае, можно сам факт попила сделать целью. Чёткой и измеримой, пусть и неформальной/скрытой от заказчика. "Попилить N миллионов рублей командой из X человек за T месяцев".
На самом деле многое лежит на умении грамотно составить SoW (ТЗ), управлять доступными ресурсами и работать с изменениями, точнее запросами на изменения. Что гораздо более чётко формализуемо, чем "чуйка".
Очевидные риски известны. На них натыкались многие уже много-много раз. Предусмотреть и закрыть или принять их можно. Всё не предусмотришь, но многое - вполне.
Это очень разные понятия.
Примерно там, где находится понимание отличий управления от общения. Свобода принятия решений в способах выполнения поставленной задачи (причем, задача может быть поставлена крайне широко) совершенно ортогональна неправильному пониманию поставленной задачи, отсутствию своевременных отчётов о статусе задачи, или возникших препятствиях в её решении. Она даже отличается от разрешения/приказа начать выполнять задачу после принятия решения о том, как её выполнять. Советую книгу "Turn the ship around!" - она как раз про это, на самом деле. Или в основном про это.
Управление изменениями - это не только и даже не столько про OKR (я надеюсь, Вы же не KPI имели в виду под измеримыми показателями?). Подавляющее большинство изменений не затрагивают OKR, но затрагивают методы их достижения.
Документирование ничем не важнее понимания целей проекта и его содержания внутри команды, грамотного планирования и менеджмента. Внутри маленькой команды, делающей небольшой проект, вполне можно достичь успеха без хорошей внутренней документации. Но вот формальное документирование без понимания, планирования и управления разве что и сможет, что с какой-то степенью успешности прикрыть зад менеджера, да и то без гарантий. Ибо провал проекта, даже грамотно прикрытый документацией, редко становится плюсом в репутацию управленца. Документирование хорошо как метод достижения пунктов 1-7, если выполняется грамотно.
Я сужу не по себе, а по опыту управления людьми и по той информации, что я изучил, чтобы хоть как-то ими управлять. И выводы я сделал, исходя из Ваших слов, а не моих.
Давайте в последний раз разберём Ваши слова. "Это для него значительный опыт для будущих работ".
Это Ваше понимание его мотивации. Либо ваша мотивация для него, то, что Вы лично ему подаёте. В любом случае эта мотивация предполагает уход данного человека после получения опыта. Куда? На "будущие работы". Не Ваш стартап.
Возникает вопрос. Это риск для стартапа - потерять ключевого сотрудника (а один из двух сотрудников в любом случае ключевой)? Риск. Всё. Надо этот риск просто признать и с ним работать. Как? Решайте сами. Я был лично убрал такую мотивацию и выбрал мотивацию, неразрывно связанную с успехом Вашего предприятия, оставив "будущие работы" в стороне. Причём, раз уж между учёбой и работой он выбрал учёбу, его обеспечивает кто-то ещё (родители), а не он сам. Следовательно, финансы его не интересуют сегодня. Это тоже надо учитывать при мотивировании.
Вы же, по ощущениям от Ваших слов, просто игнорируете этот риск. Ну какое отношение Ваш стартап имеет к конфликту между учёбой и работой? Да никакого. Поэтому неудивительно, что Вас он оставил как есть - Вы не мешали ни учёбе, ни работе. Но Вы используете этот конфликт как оправдание отсутствия риска для Вас. А на самом деле, это дополнительный риск. Что если Ваше предприятие начнёт мешать учёбе? Что он выберет? Вы знаете ответ на этот вопрос, обсудили с ним это?
Кроме того, не могу не заметить, что Вы, в отличие от меня, взяли на себя смелость судить обо мне исходя не из моих слов, а исходя либо из личной обиды, либо, как раз, судя по себе. Вы не знаете обо мне и моей мотивации ровным счётом ничего.
И по своему опыту работы в стартапе, ради которого я переехал за 10К+ км на весьма изначально скромную з.п., потеряв для своей семьи очень сильно в качестве жизни на несколько лет, работая буквально за еду и жильё, я могу сказать, что очень важно, крайне важно сотруднику понимать чётко, что его ожидает в случае успеха и в случае провала. И в чём конкретно измеряется успех или провал.
И не надо полагать, что сотрудник умеет читать Ваши мысли. Нужен прямой разговор об этом с расставлением всех точек над i. Просто "разделим 50/50" недостаточно, т.к. под этим каждый понимает что-то своё и это никак не отражает того, кто какую роль будет в будущем играть. Кромет того, часто не получается сохранить 50/50, т.к. обычно появляются миноритарные совладельцы, размывая доли владения.
Мне не нужно знать ни о чём Ваш продукт ни где находятся Ваши клиенты, чтобы видеть, что мотивация разработчика "наберусь опыта, чтобы работать где-то ещё" рискована для Вас лично. На что именно он при этом согласился - дело вторичное, если не десятое. С такой мотивацией он уйдёт сразу же, как только получит хороший оффер. Про создание клона я не писал ничего.
В любом случае удачи Вам и Вашему компаньону.
Я вижу два огромных риска в Вашем комментарии.
1. Сам разработчик. Почему оплатой вашего "CTO" является "значительный опыт для будущих работ"? Каких таких "будущих работ"? Он собирается использовать Ваш стартап как стартовую площадку для "корпоративной" карьеры? Тогда Вы лично в огромной беде - Вы запрограмированы на то, что лишитесь единственного человека, который досконально знает Ваш продукт с технической стороны. У вас есть, хотя бы, юрлицо и контрактные обязательства между вами обоими и этим юрлицом? Доли расписаны юридически, или всё на словах?
2. Ваш друг. Вы используете своего друга как ментора для обучения неопытного разработчика, который хочет уйти как только наберётся опыта. Что, если Вашему другу надоест?
В сумме по Вашему описанию, Вы завязаны на двух людей, не особо замотивированных в том, чтобы Ваш стартап развивался. Один менторит ради собственного интереса, другой разрабатывает ради опыта.
Ну и не надо обманываться, никакой ответственности никто из вас не берёт. Любой из вас может отвалиться в любой момент и не понесёт никаких потерь. Ни финансовых, ни репутационных. Вы вкладываете своё время, но и в хобби люди вкладывают время и даже деньги и никому в голову не приходит называть занятие хобби ответственностью.
Не поймите меня неправильно, я желаю Вам и Вашей команде успеха. Более того, я сам ни шатко не вяло занимаюсь своим личным стартапом в свободное от работы время. Но это не бизнес подход, это хобби. Основная моя работа - как раз "СТО" стартапа, проданного большой компании.
До тех пор, пока вы или я не начнём вкладывать деньги или финансовые обязательства в какой-то форме (инвестиции, деньги клиентов в обмен на обещание услуги или товара, деловую репутацию) в предпринимательскую деятельность, осуществляя это на свой страх и риск, мы оба занимаемся хобби, а не предпринимательством/бизнесом (кстати, в английском это связанные, но разные понятия).
Интересный опыт, из которого думающий человек может сделать множество полезных для себя выводов. Зря минусуете. Хотелось бы увидеть картину и с другой стороны, но и так можно многое увидеть и использовать, если хотите поучаствовать в стартапа в роли CTO.