Yandex.Kit был по большей части очень неплох. Какое-то время была надежда что они будут продолжать в том же духе и постепенно разработчики подтянутся и на Yandex.Store. Через полгода ожидания из машины вытащили забытый там Explay Flame. Это, пожалуй, был единственный раз, когда потеря телефона принесла радость.
Спасибо за объяснение.
С позиции инвестора (покупателя) желание иметь удобный в доработке продукт понятно. Откровенно говоря, мне не знакома процедура оценки качества исходного кода ПО при его покупке и выполняется ли она вообще. И, хотелось бы где-нибудь почитать об этом (как до покупки и без передачи исходников производится оценка оторванности продукта от команды). А вот ситуация попавшей в зависимость от разработчика компании и сейчас имеет место быть. Т.е. по факту разработчик программы заработал на продаже продукта. И продолжает получать деньги за его доработки, имея возможность в любой момент помахать рукой и передать привет штатным сотрудникам.
И, как показывает практика того же производства автомобилей: покупают не только готовую продукцию концерна, создающего автомобили в которых для замены лампы требуется снимать бампер или, в качестве временной меры, выполнять эту замену со снятием колеса. Покупают и технологии производства и даже перенимают опыт у таких инженеров.
Что-то я не очень хорошо понял: в начале про проект на продажу, а в конце про проект на поддержку.
Нехорошо так говорить, но если продукт полностью делается для заработка на разовой продаже, то от него в первую очередь нужно чтобы он правильно работал и красиво выглядел, а не был прост и лёгок в доработке.
На мой взгляд: друзья с работы и работа с друзьям — несколько разные вещи.
В первом случае дружбы не получится, если сотрудники будут сдавать халтуру и иными способами "подставлять" своего руководителя перед вышестоящим руководством. Так же, как и не получится её, если руководитель не будет ограждать своих сотрудников от, например, несвойственных им задач и прочих горестей.
Во втором случае — сотрудник будет либо считать себя обязанным тянуть лямку, если это в самом деле друг, либо, если это просто приятель или знакомый, то как выше написал AntonSor, будет сдавать халтуру. И наоборот: друг-руководитель будет стараться прикрывать нерадивого сотрудника, а друг-приятель требовать большего, чем от других сотрудников того же уровня.
Т.е. unix-way, если я правильно понимаю — набор небольших кубиков, каждый из которых делает свою работу хорошо и может быть при необходимости заменён аналогичным с недостающим функционалом, вместо одной большой собранной в монолит системы.
В целом то, что и предлагается в статье — куча проектов, каждый из которых, при грамотной проектировке, может быть убран/заменён или добавлен новый?
Согласен. Аналогично с тех.поддержкой: пообещали клиентам ответ в течении часа. Ближе к концу часа клиенту отправлялся ответ в стиле «мы работаем над этим». В итоге работы по отпискам добавилось, сроки полных ответов остались такими же, а руководство компании какое-то время пребывало в уверенности, что компания стала работать лучше.
К примеру кто должен определять что выбранная для решения библиотека полностью подходит для использования?
Т.е. к примеру поставили задачу — взять что-нибудь для работы с soap и сделать плюшку. Разработчик взял библиотеку, сделал плюшку. После этого поставили задачу добавить ws-security, а этого выбранная библиотека не умеет.
По моему мнению, это всё должно продумываться архитектором, который ставит задачи руководителям направлений, которые в свою очередь раздают задачи по отделам. Но в данном случае выходит больше одного уровня в иерархии проекта, что в целом не есть хорошо?
Или я всё не так понимаю?
Жаль что с четвёртым пунктом почти везде беда. Захотели люди тишины ночью. Чтобы спать. И сделать так, чтобы те кто спать мешают несли за это ответственность (бабушки, конечно, хотели чтобы она была уголовной). Скрипя зубами и подтягивая пояса выделили денег на работу законодательного собрания. И получили точный список ночных дел за которые наказывают. И пункт, делающий этот список бесконечным: «иные действия». Т.е. по букве закона: тишину нарушать нельзя никак. Мужчинам всё-таки нельзя храпеть, женщинам — стонать, котам — топать, детям — кричать во сне при болезни. Конечно если эти граждане не занимаются деятельностью «при отправлении ими религиозных культов в рамках канонических требований соответствующих конфессий».
И если я правильно понимаю, то во славу давно забытых богов барана ночью можно зарезать (с песнями и танцами). А вот барану при этом мекать нельзя.
Где бы ещё узнать условия, на которых проводится финансирование? Где-то встречал что в зарубежных странах обычное деление долей в предприятии 76/24, тогда как у нас, для небольших проектов, обычное предложение — 51/49.
Да, второй абзац это не описание европротокола. Просто вариант не ждать сотрудников ГИБДД на месте несколько часов.
Да, страховая откажет и придётся отдать дело юристам, которые сами стрясут с виновника и стоимость ремонта/замены, и своих услуг. Поэтому, на мой взгляд, появление виновника на осмотре в интересах самого виновника.
Европротокол — оформление ДТП без участия сотрудников ГИБДД.
Т.е. каждой стороной заполняется бланк извещения о ДТП и водители разъезжаются. Виновник — откладывать деньги на повышение страховки, потерпевший — в свою страховую.
Если совпали звёзды на небольшие повреждения и оба участника адекватны и имеют возможность, то с этими бланками (а впрочем можно и без них), вместе едут в гаёвню, мучают инспектора глупыми вопросами, рисуют схему, инспектор осматривает ТС и составляет справку о ДТП, объясняет что стоит написать в пояснении, выдаёт справку о ДТП и постановление/отказ об административном правонарушении.
Перед отъездом из ГИБДД нужно вписать в бланк извещения о ДТП номер бляхи инспектора и поставить галочку что оформление производилось не самостоятельно.
С этим расширением комплекта документов на ТС потерпевший идёт в страховую.
По этому варианту время ожидания зависит только от очереди к инспектору. Мы разъехались по домам чуть больше, чем через час после самого столкновения. Страховая тоже никаких проблем не доставила — осмотр сделали в тот же вечер и через неделю перевели деньги.
С позиции инвестора (покупателя) желание иметь удобный в доработке продукт понятно. Откровенно говоря, мне не знакома процедура оценки качества исходного кода ПО при его покупке и выполняется ли она вообще. И, хотелось бы где-нибудь почитать об этом (как до покупки и без передачи исходников производится оценка оторванности продукта от команды). А вот ситуация попавшей в зависимость от разработчика компании и сейчас имеет место быть. Т.е. по факту разработчик программы заработал на продаже продукта. И продолжает получать деньги за его доработки, имея возможность в любой момент помахать рукой и передать привет штатным сотрудникам.
И, как показывает практика того же производства автомобилей: покупают не только готовую продукцию концерна, создающего автомобили в которых для замены лампы требуется снимать бампер или, в качестве временной меры, выполнять эту замену со снятием колеса. Покупают и технологии производства и даже перенимают опыт у таких инженеров.
Нехорошо так говорить, но если продукт полностью делается для заработка на разовой продаже, то от него в первую очередь нужно чтобы он правильно работал и красиво выглядел, а не был прост и лёгок в доработке.
В первом случае дружбы не получится, если сотрудники будут сдавать халтуру и иными способами "подставлять" своего руководителя перед вышестоящим руководством. Так же, как и не получится её, если руководитель не будет ограждать своих сотрудников от, например, несвойственных им задач и прочих горестей.
Во втором случае — сотрудник будет либо считать себя обязанным тянуть лямку, если это в самом деле друг, либо, если это просто приятель или знакомый, то как выше написал AntonSor, будет сдавать халтуру. И наоборот: друг-руководитель будет стараться прикрывать нерадивого сотрудника, а друг-приятель требовать большего, чем от других сотрудников того же уровня.
Но иногда совещания в самом деле нужны.
В целом то, что и предлагается в статье — куча проектов, каждый из которых, при грамотной проектировке, может быть убран/заменён или добавлен новый?
Т.е. к примеру поставили задачу — взять что-нибудь для работы с soap и сделать плюшку. Разработчик взял библиотеку, сделал плюшку. После этого поставили задачу добавить ws-security, а этого выбранная библиотека не умеет.
По моему мнению, это всё должно продумываться архитектором, который ставит задачи руководителям направлений, которые в свою очередь раздают задачи по отделам. Но в данном случае выходит больше одного уровня в иерархии проекта, что в целом не есть хорошо?
Или я всё не так понимаю?
А кем должна проводиться проверка контроля качества? Выноситься в отдельный проект или как?
И если я правильно понимаю, то во славу давно забытых богов барана ночью можно зарезать (с песнями и танцами). А вот барану при этом мекать нельзя.
Да, страховая откажет и придётся отдать дело юристам, которые сами стрясут с виновника и стоимость ремонта/замены, и своих услуг. Поэтому, на мой взгляд, появление виновника на осмотре в интересах самого виновника.
Т.е. каждой стороной заполняется бланк извещения о ДТП и водители разъезжаются. Виновник — откладывать деньги на повышение страховки, потерпевший — в свою страховую.
Если совпали звёзды на небольшие повреждения и оба участника адекватны и имеют возможность, то с этими бланками (а впрочем можно и без них), вместе едут в гаёвню, мучают инспектора глупыми вопросами, рисуют схему, инспектор осматривает ТС и составляет справку о ДТП, объясняет что стоит написать в пояснении, выдаёт справку о ДТП и постановление/отказ об административном правонарушении.
Перед отъездом из ГИБДД нужно вписать в бланк извещения о ДТП номер бляхи инспектора и поставить галочку что оформление производилось не самостоятельно.
С этим расширением комплекта документов на ТС потерпевший идёт в страховую.
По этому варианту время ожидания зависит только от очереди к инспектору. Мы разъехались по домам чуть больше, чем через час после самого столкновения. Страховая тоже никаких проблем не доставила — осмотр сделали в тот же вечер и через неделю перевели деньги.