Напряжение другое, но если внимательно посмотреть на блок питания, то в большинстве случаев внезапно окажется, что он умеет в
Что за внутренний клиент? И что там насчет требований?
Эх, и снова мой любимый аутсорсинг головного мозга. Убери «заказчик» и «требования» — и от статьи вообще ничего не останется...
В Германии такой вариант есть, но есть и нюанс: «ФОП» не может работать только с одним «заказчиком» — это расценивается как уход от налогов.
тех уж нет — не могу ничего сказать, а на 35 нету (и даже кабель с тремя контактами)
Ничего интересного в контексте обсуждения наушников.
Но, кстати, сидеть в наушниках-шумодавах без всякой музыки, только под шумодавом — достаточно странно, надо к такому привыкать. Сходу мозг чувствует что «что-то не так», и требуется некоторое время на адаптацию.
Ходить по улице / кататься на велике местами просто опасно.
В один прекрасный день у нас в команде встал выбор — все в большом опенспейсе или в нескольких разных комнатах. Мы выбрали опенспейс + купили всем bose qc25 (35 тогда еще не вышли). Сработало отлично — во-первых, это очень хорошие наушники с отличным подавителем, так что находиться в относительно шумной комнате стало заметно комфортнее. Во-вторых, люди, которые сидят в наушниках не реагируют на всякие разговоры и не подключаются к ним — от этого разговоров вообще в целом стало меньше.
(Если б им еще микрофон — вообще супер-девайс был бы!)
Есть тут один конкурентик...
Тесен мир!
В 10 классе у меня появился свой собственный ключ от школьного компьютерного кабинета, а в 11 классе мне открыли трудовую книжку и официально трудоустроили в родной школе — я получил полставки лаборанта при кабинете информатики.
Если я все правильно понимаю, это моя школа, и именно благодаря Андрею в этом самом кабинете «в порядке факультатива» сидела и определенная группа школьников, имевших тягу к компьютерам, а среди них и я. Спасибо, Андрей!
Мне кажется, главный вопрос — это насколько правдоподобно предположение, что люди станут учить в обмен на учение (мне кажется, что «учителей» на порядки меньше, чем «учеников»), ну и цена привлечения таких пар.
По моему опыту поднимать деньги — это длительный процесс, и если искать всего на полгода, то поиском следующего раунда надо начинать заниматься в день получения предыдущего. Полгода на поднятие раунда — нифига не слишком много. То есть, с точки зрения инвестора я бы ждал вопроса «а почему только на полгода?» — вы дальше планируете выйти на операционную прибыльность?
Чувак, тебе только что уже прямым сказали, что ты неправильно понял закон, а ты продолжаешь его критиковать? Фактически признав, что не читал и не разобрался?
Да что это за мифические best practices выработанные для большинства кейсов? Которые еще и не требуют мнения заказчика? Ссылку? А то пацаны-то и не знают, бьются за что-то, новые подходы пробуют, экспериментируют зачем-то.
Задача разработчика использовать их и убедить заказчика, что это хорошо. В общем случае, бизнес не должен разбираться в тонкостях разработки ПО — это не его компетенция. И если на разработчика возлагается ответственность за качество, то да, разработчик вправе выставлять свои требования к процессу и средствам разработки.
Ну, если нужна была еще одна иллюстрация про АГМ и как не делать customer collaboration — то вот она.
Так что — есть всего, стало быть, три подхода —
— херак-херак и в продакшен
— сколько-нибудь долгую поддержку и развитие решения
— всякого рода life-critical системы
А чего ж методологий разработки в десять раз больше, если всего-то три типа проектов с понятными «как надо»?
Я считаю DoD отличным инструментом и значимым артефактом agile разработки. Той самой agile разработки, четверть манифеста которой заключается в принципе:
Customer collaboration over contract negotiation
И DoD, что характерно, является именно что разновидностью contract. И хотя коллаборация с клиентом намного важнее этого контракта — он все же есть в методологии, и польза его не вызывает сомнений. Мне кажется, это именно потому, что соглашение по поводу базовых терминов является основой здоровой customer collaboration. Чтобы фраза «it’s done» не вызывала в будущем боли несоответствия ожиданиям, а вызывала приятную улыбку взаимопонимания. И мне кажется, что это важный момент в понимании смысла и назначения DoD. Потому что тут может случайно произойти подмена. И, кажется, происходит.
Есть такая штука — профессиональные деформации. Психологические паттерны, связанные с определенной работой. Работа в аутсорсинге тоже обладает своими характерными особенностями, с которыми приходится сталкиваться. И у тех, кто достаточно долго работал в аутсорсинге (а то и вообще всегда) может сложиться впечатление, что вся разработка софта — она вот такая, как в аутсорсинге, ну плюс-минус. Когда такие люди рассуждают о разработке вообще, не в контексте аутсорсинга — это хорошо слышно, потому что они проецируют свой аутсорсинговый опыт на видение разработки в целом. Я называю это Аутсорсинг Головного Мозга.
И вот перед нами такая статья — о разработке вообще, о Definition Of Done — концепции, никак не связанной с аутсорсингом, не имеющей никаких аутсорсинговых коннотаций. Тем не менее, из стати хорошо слышно, что автор вовсе не практикует и не собирается практиковать customer collaboration! Более того, старается его минимизировать, и как раз считает, что DoD — это путь к минимизации коммуникаций (еще бы, она названа Болью в статье!).
Так вот, мне кажется, что статья практически полностью про АГМ на примере DoD.
Какие маркеры говорят от этом? Это, конечно, «Клиент» и «Заказчик», красной линией проходящие через статью. В разработке софта вообще есть, конечно, разные стейкхолдеры, и налаживание отношений между ними — сложное и важное дело, но именно в аутсорсинге (и другой сервисной разработке) эти роли так сильно акцентированы: ведь две компании пытаются работать вместе при совершенно разной парадигме бизнесов. Тут и продажи, и формирование ожиданий и контракт и приемка и все остальное — целое ремесло по работе с клиентом, которого... совсем нет в компании, которая сама себе разрабатывает. И Боль вокруг Клиента — это следствие аутсорсинга в куда большей степени, чем необходимости четкой работы стейкхолдеров в разработке вообще.
Но самое ужасное, что по многим фразам становится ясно, что никто не умеет в customer collaboration!
Например:
— код написан;
— юнит-тесты написаны и успешно выполнены;
— код прошел ревью;
— документация обновлена;
— функциональное тестирование успешно завершено;
— регрессионное тестирование успешно завершено.Чем больше и объемнее Definition of Done, тем более строгим оно считается. И тем больше нужно времени и усилий, чтобы наш функционал добрался до желаемого состояния «сделано». И тем выше вероятность, что функционал будет работать в соответствии с ожиданиями бизнеса.
Это же ужасно. Посмотрите на предлагаемое DoD — в нем нет ничего, что можно трактовать как ожидание бизнеса. Разве бизнес хоть капельку волнует, был ли код ревью? Тут все меры — про минимизацию багов (и это тоже характерная фиксация аутсорсинга, кстати). При этом то, что бизнес могло бы волновать — тут начисто отсутствует: где «можно пощупать на стейджинге» или «выкачено на продакшн»? Покажите мне бизнес, который не волнуют эти вещи в критерии «готовности»?
Почему так? Да потому что АГМ, и никто не хочет думать и говорить о проблемах кастомера. Почему я так думаю? А вот:
В сухом остатке у нас есть человек, который знает или думает, что знает, ЧТО делать, и не обязан знать КАК, и есть группа людей с горящими глазами, которая знает КАК, но пока не знает, ЧТО именно.
Разве это выглядит как призыв к customer collaboration? Да это прямо противоположная движуха — мы к тебе не лезем и ты к нам не приставай. Может, показалось?
С учетом вышеизложенного, весь процесс коммуникаций по ходу разработки представляет собой, с одной стороны, трансляцию Клиентом Команде бизнес-требований, а с другой — трансляцию Командой Клиенту необходимых для реализации сроков и текущего статуса разработки этих самых требований.
В этом месте каждый уважающий себя адепт аджайла должен встать, махом перевернуть стол и крикнуть «bullshit!» — потому что это прямо противоположно принципу customer collaboration over contract negotiations.
Вот примерно из этих соображений я пытаюсь аккуратно намекнуть — а что, если бы уберем аутсорсинг из этой статьи — что мы получим? Каков будет ответ на заглавный вопрос? Зачем нужен DoD если нет Клиента/Заказчика, а работа идет внутри одного коллектива? И окажется, что единственная фраза в статье, начинающаяся с «потому что...» это
Потому что если ваш цех по производству Kotlin-пасочек станет хронически обгонять цех RxSwift-пасочек по причине отсутствующего или гораздо менее строгого Definition of Done, мобильная разработка рискует превратиться в храм боли. Боли при общении с Клиентом.
И это слабенькое понимание роли DoD — зато сильный знак огромной проблемы в общении с Клиентом. Ну и попытка решить ее с помощью всех доступных средств, годных или нет.
Знаете, какой еще характерный маркер АГМ?
В сухом остатке у нас есть человек, который знает или думает, что знает, ЧТО делать, и не обязан знать КАК, и есть группа людей с горящими глазами, которая знает КАК, но пока не знает, ЧТО именно.
Аутсорсинг так яростно продает «экспертизу, комплиментарную вашему пониманию бизнеса», что и сам в это верит — что мир устроен по принципу чистых функций и должностных инструкций, и их можно докупать и совмещать как ликвидные универсальные ресурсы. А это только защитный механизм в аутсорсинге, и ничего общего с customer collaboration не имеет.
Такие дела.
DoD — это вопрос из серии как надо делать
Как надо кому?
Или, простите, есть «как надо» одно на всех годное?
Есть человек из бизнеса, и есть команда, которая в бизнесе не разбирается.
Это чудесный мир картонных чучелок, где ты или туда или обратно и все (относительно) просто.
Давай предположим, что человек из бизнеса строит не первый бизнес. В каждом из них он занимался именно бизнес-частью, но успел столкнуться с: несколькими неудачными СТО, многократно невыдержанными сроками разработки, лекциями о сложности и непредсказуемости мира ИТ и нечеткой природы оценок, сорванными контрактами и поставками, перегруженным колл-центром после релиза недотестированой версии. Один его бизнес был энтерпрайзным, би-ту-би-шным, с тяжелыми многолетними контраткми с неустойками, другой — стартапом в другой области, с быстрыми итерациями и тестированием на живых пользователях.
Можно ли сказать, что он совсем уж не разбирается в производстве программного обеспечения?
Или вот, скажем, программист — он же не джуниор из университета наверное, он где-то работал раньше. Однажды в одном легаси-проекте, где нужно было крыть тестами и рефакторить, а заказчик плохо говорил на английском, так что надо было убеждаться письменно, в а другой раз в автомотиве скажем, где была цепочка вендорских поставок с четким графиком, и было важно успевать в твердые даты потому что от этого зависели другие команды. Он уже не раз видел как, бывает, меняются требования на лету, и знает когда такое бывает от неопределенности рынка, а когда — от рукожопости менеджмента. Видел смерть от регрессии, и когда команда долго пренебрегает тестированием может найти слова и аргументы для бизнеса чтобы обратить внимание на это.
Можно ли сказать, что он совсем уж не разбирается в бизнесе?
Ты готов встать между ними с плакатом «Источником DoD должна быть технология, а не бизнес» и выдать им нарукавные повязки «ЧТО» и «КАК»? Или, возможно, двум интеллигентным людям с разносторонним опытом есть о чем поговорить на равных и прийти к понятному и прозрачному взаимному соглашению?
Затем, что мы должны договориться до одинакового понимания одинаковых вещей.
Золотые слова! Но почему же одинаковое понимание вещей всенепременно должно проистекать от технокоманды?
Я так понимаю, что теперь проще делать универсальный питальник110-220 чем делать разные питальники для разных регионов.