Интересное обьяснение, все понятно. А в чем тогда разница между выпуском акций и собственной валюты? Т.е. зачем компании выпускать свою валюту, если можно выпустить акции?.. Акция ведь тоже своего рода обязательство. Ну, кроме технической стороны дела, что валюта ликвиднее чем акции.
Хотелось бы понять чем подкреплена такая «самодельная» крипютовалюта?
Например выпустил я икс-коин, и изначально они есть только у меня. Я например, вместо того, чтобы работать за еду, могу требовать оплату икс-коинами, вместо гамбургеров. Но, чтобы получить икс-коины, закачзчик сперва должен их у меня купить. Получается он заплатит дважды. Ерунда получается. Где в моих рассуждениях ошибка?
люблю когда статья расширяет кругозор. Про механического турка историческая отсылка понравилась. Жаль чаще статьи ограничиваются техническим минимумом, без лирических отступлений.
да, и тестировщик интуитивно (по опыту) знает какие комбинации стоит проверить а какие бессмысленно. позитивный кейс тестировщик даже проверять не станет, его уже 100 раз проверил разработчик.
У нас приложение поделено на функциональные разделы. У каждого раздела свой подрядчик. Мы делаем три раздела из двенадцати. В каких-то командах четверо пишут ui-автотесты на один раздел, у нас один пишет на три.
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
я честно говоря подумал тоже самое. Но обьясню. Если понаблюдать за развитием языков программирования, то одни появляются чтобы избавиться от недостатков других. Но и они не получаются без недостатков. Поэтому возникает резонный вопрос, а надо ли оно в таком количестве. На самом деле надо — потому что прийти к совершенству можно только через эволюцию или революцию. Но скорее через революцию, потому что при эволюции мы пользуемся знанием предыдущих поколений, а они не совершенны и максимум, что получится в конце эволюции — идеальная раскоряка :) А при революции создается что-то принципиально новое. Получается, продолжу рассуждение, что если посредством революции не получилось идеального результата, скорее всего нет смысла его улучшать, а нужно готовить следующую революцию.
У немцев тоже есть эта аналогия с мячом только из футбола. И смысл такой.: не можешь реализовать ситуацию — передай мяч. Вполне позитивный смысл. Не тормозить ход дела без причины.
Намедни купил и начал играть в D:OS EE, а тут такое совпадение. Игра бесспорно уникальная.
Хотелось бы узнать почему отказались от локализованой озвучки. Это частое явление среди игр и хотелось бы узнать отчего так происходит, что при одинаковой цене за копию одни игры полностью дублированы (например тот же Диабло 3), а другие нет.
имхо, работа программиста сродни работе переводчика. Он переводит из человеческого языка в машинный. Мне эта аналогия кажется достаточно точной чтобы предположить что все проблемы связанные автоматизированным переводом будут и у системы автоматизированой кодогенерации.
Клиент обратился: «А можете сделать и маркетинг кит?» — «А почему бы и нет — это ведь дополнительные деньги!» И вот в этот момент происходит главная ошибка молодой компании — создание маркетинг кита — это увеличение объема ..
Я просто выделил из этого примера систематическую ошибку, которой страдают компании, с учетом личного опыта.
а есть такие руководители, что от их присутствия или отсутствия ни тепло ни холодно :) И это плохие руководители. Любая компания будет продолжать работать в отсутствие руководителя. Просто раньше для принятия решения бежали к начальнику перекладывая решение на него, а без начальника или переложат решение на кого-то другого или примут его сами. Вот тезис, что черезмерная вовлеченность начальника в деятельность сотрудников делает сотрудников несамостоятельными, возможно верен.
Я думаю что причина краха IT-предприятий именно в том, что они набирают проекты не сверяясь с ресурсом и компетенциями. Т.е чтобы этого избежать нужно делать то, что ты умеешь делать хорошо, и не браться за то, о чем имеешь смутное представление. И обычно так фирмы себя и ведут. Но в кризисные времена, когда есть риск потерять заказы, они могут начать «метаться», а этого делать нельзя. (Кому интересно, почитайте вот яндекс-поиск: "почему нельзя снижать цены в кризис" — из той же оперы)
мне бросилось в глаза, что например «ведение финансов» это деятельность, а «отправить письмо» это действие. В картинке с облачками их представили одинаково. Атомарные действия и процессы нельзя ставить рядом.
Процессы состоят из атомарных действий и решений.
И по второму моменту: фирма берет все заказы подряд, не обязательно разбираясь в специфике заказа: «мы же IT-компания».
У нас такая ситуация как раз наличествует. Взяли еще один проект, дополнительную часть приложения, одну часть которого мы уже делаем. А оказалось что над разными компонентами одной и той же системы не одинаково просто работать. Понятно что фирма ведет себя как фирма, бизнес, деньги, и это для оррганизации правильно. Но вот то что человеческий ресурс при этом планируется после получения заказа… За это надо ставить к стенке и вести серьезный разговор. И сразу, иначе посмотрят что «ну тянут ребята» и притащат еще один проект.
А вообще мне кажется анализ процессов «на салфетке» это опасно. Перераспределение говна киселя не приводит к уменьшению общего количества киселя.
Да, при таком подходе есть недостаток, что завалившийся тест перекрывает «видимость» на следущий за ним функционал. И пока причина не будет устранена, эти перекрытые части остаются непротестироваными. С другой стороны, по скольку багрепорты пишу тоже я, а мой ресурс не бесконечен, такой подход работает. Писать тест так чтобы он выполнялся в любом случае, заставило бы нас сильно залезать во внутреннее состояние системы, а это во первых на нашей системе очень сложно (при проектировании тестируемость в нее не закладывали), во вторых черевато побочными эффектами.
Я подразумевал, что из экономического факультета произрастают менеджеры. На западе это распространенный карьерный путь. Вы видимо имели ввиду экономиста в его первородном виде: экономист-оптимизатор.
Если бы только правило Гудхарта включали в программу обучения экономистов, то бестолковых менеджеров было бы немножко меньше.
Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
Я еще несколько раз перечитал ваш ответ, и понял что же меня при первом прочтении резануло: по вашей логике продукт со сломаным логином можно выдавать пользователю? И зачем оно ему если он даже зайти в систему не сможет?
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Например выпустил я икс-коин, и изначально они есть только у меня. Я например, вместо того, чтобы работать за еду, могу требовать оплату икс-коинами, вместо гамбургеров. Но, чтобы получить икс-коины, закачзчик сперва должен их у меня купить. Получается он заплатит дважды. Ерунда получается. Где в моих рассуждениях ошибка?
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
У немцев тоже есть эта аналогия с мячом только из футбола. И смысл такой.: не можешь реализовать ситуацию — передай мяч. Вполне позитивный смысл. Не тормозить ход дела без причины.
Хотелось бы узнать почему отказались от локализованой озвучки. Это частое явление среди игр и хотелось бы узнать отчего так происходит, что при одинаковой цене за копию одни игры полностью дублированы (например тот же Диабло 3), а другие нет.
Я просто выделил из этого примера систематическую ошибку, которой страдают компании, с учетом личного опыта.
Процессы состоят из атомарных действий и решений.
И по второму моменту: фирма берет все заказы подряд, не обязательно разбираясь в специфике заказа: «мы же IT-компания».
У нас такая ситуация как раз наличествует. Взяли еще один проект, дополнительную часть приложения, одну часть которого мы уже делаем. А оказалось что над разными компонентами одной и той же системы не одинаково просто работать. Понятно что фирма ведет себя как фирма, бизнес, деньги, и это для оррганизации правильно. Но вот то что человеческий ресурс при этом планируется после получения заказа… За это надо ставить к стенке и вести серьезный разговор. И сразу, иначе посмотрят что «ну тянут ребята» и притащат еще один проект.
А вообще мне кажется анализ процессов «на салфетке» это опасно. Перераспределение
говнакиселя не приводит к уменьшению общего количества киселя.Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.