Eco-Friendly - это про потребление энергии на реализацию консенсуса. По сравнению с PoW в эфире и биткоине почти все блокчейны, с консенсусом без доказательства работой, считают себя Eco-Friendly
Если вести задачи, то совокупные данные по ним могут закрыть потребности в аналитике рентабельности. Оговорка, если вести их
Обычно
Вам нужно измерить рентабельность проекта а не время выполнения каждой задачи, и тут простое суммирование времени выполненных задач к выделенному времени разработчиком. Ведь новые выполненные задачи ровно также влияют на это соотношение, если нет, то кто-то поленился оформить изменения в виде задач. А фильтрация по дате создания - данные для графика внесенных изменений в процессе разработки
Разработчики не роботы, задача сделанная за X весной, не будет сделана за X зимой. Разный эмоциональный фон, разный контекст, разные параллельные проекты. Оценка выполнения конкретной задачи не имеет ценности с точки зрения бизнеса
Изменилось все, поменяйте все невыполненное
Изменилась задача поменяйте эстимейт ее
Изменились приоритеты, будут сделаны сначала другие задачи, а прежние скорее всего останутся но будут отодвинуты
Выполненное - факт созданной работы в рамках выделенного на это времени разработчика. Не важно сколько именно заняла каждая. Важно укладывается ли это в общий таймлайн или надо приоритеты менять.
И есть еще не выполненное, которое тоже хорошо суммируется и показывает будущее с незавершенным проектом в оговоренные с заказчиком сроки :)
Человеческий фактор в оценке своего времени потраченного на задачу точно не лучший показатель для таких расчетов
У вас всегда есть фактическое прошедшее время и реализованый за это время функционал. Чем лучше декомпозированы задачи на старте тем точнее эcтимейт. Где-то время завышено, где-то занижено, но если при декомпозиции подумали о всех мелочах даже на 10 - 15 минут, то в среднем эстимейт при достаточном опыте будет выполняться
Если на старте у вас задачи хорошо декомпозированы. Вынести задачи на таймлайн, то всегда отлично видно как движется разработка и успеваете ли в общие обозначенные рамки рентабельности
Дорогие менеджеры и тимлиды заставляющие отмечать время, покажите как выглядит ваша итоговая статистика за пол года и какие выводы она позволяет делать?
Она точно стоит 150 часов рабочего времени дорогостоящих разработчиков и дизайнеров за пол года?
15 минут * 5 участников команды * 20 дней в месяц * 6 месяцев? А это между прочим где-то от 150 000 до полумиллиона за пол года? Такая статистика точно окупается? Нельзя ли как-то автоматизировать сбор данных после выполненных задач и экономить до миллиона в год на квалифицированной команде из 5 человек?
Что люди делают с удовольствием - это закрывают задачи.
Что сложного считать когда какая задача была закрыта? И эстимейтить их?
За десяток лет в отрасли, лично для меня очевидно, что кто-то вместо грамотной декомпозиции и эстимейтов перекладывает работу на разрабов требуя в конце дня еще и время отмечать и следить сколько раз их отрывали от работы с разными вопросами и пожарами.
Разработчик эмоционально переходит в режим оправдания за потраченное время, хотя довольно честно использует все свои ресурсы на работу и старается.
Отмечание времени - это эмоционально сложный процесс. Требующий подведение итога в конце сложного дня. Итог в котором ты должен оценить себя, но так чтобы не показаться плохим разработчиком, но не уменьшить затраченное время и грамотно для "девочек" описать почему потратил несколько часов на баг созданный случайно и решеный одной строкой и которого естественно не было в эстимейте.
Не люблю когда менеджмент начинает попытки ведения статистики не со своего обучения декомпозиции, а с гипотез о том что отмечание времени другими сделает за него его работу
Много раз пробовал сам на своей команде, если нужно тщательно отслеживать прогресс - декомпозиция работает великолепно нужно не бояться даже сотен мелких задач. А все истории с отмечанием времени заканчиваются в тот момент когда на статистику забивают а разраам не показывают реального профита от возложенной на них работы
Консоль платформы 4me максимально понятна и удобна для пользователей.
В таких инструментах ожидаешь заботу о клиентском восприятии
простота
лаконичность
контроль фокуса внимания
возможность работать с разных устройств при этом иметь одинаковую механику взаимодействия
Кнопочка перевода, возможно, ускоряет работу, но вот дизайн способен снизить нагрузку на восприятие и увеличить время общей работы
Неряшливый набор и группировки, плохая работа с типографикой
Лишние плотные линии
Разные цветовые блоки и яркие пятна
Очень много элементов усложняющих чтение. Вроде мелочь, но при длительной работе накапливается
В 2021 году лично я хотел бы увидеть как рекламируют систему одинаково удобную и на мобильном и на десктопе. Где половину рутины можно сделать еще по пути на работу
Ну как я понимаю, коллекционеры мыслят десятилетиями вперед.
Область новая и в ней не хватает инструментария. Как только появятся инструменты поиска похожих произведений, будут алгоритмы оценки копий и не копий, какие нибудь DAO которые смогут принимать решения считать ли файл копией или новой работой.
Вот тогда все будет приобретать больший смысл. Наверно. Как и с ценными бумагами это вложения в потенциальную выгоду, а не гарантированные проценты в банке.
Обычно решается взятием хеша от файла. Он имеет фиксированную длину, а алгоритм хеширования с большой долей вероятности обеспечивает уникальность его для каждого набора байт (картинка, видео, текст). По крайней мере, крайне сложно изменить объект таким образом чтобы хеш от него остался прежним.
Ссылка, действительно, не дает надежности. Но если ты продаешь твит, то без твиттера он бесполезен.
Базовый алгоритм - взять файл и проверить записи о нем в блокчейне. А не из блокчейна найти где хостится файл.
Вообще, у меня нет проблемы с проектированием и рисованием проекта в том-же SketchUp. Но наблюдаются сложности когда надо обсудить, проговорить и внести коррективы.
Основные задачи:
изменения мог вносить не только я.
обсуждения проходили быстрее с проверкой разных гипотез
результат должен быть красиво оформлен для дальнейшего использования в следующих стадиях
а если можно повесить на стену - вообще шикарно
А в силу того что компьютер и время за ним - тоже ресурс. То, трехмерное моделирование хотелось бы делать уже после. Но и иметь возможность внести правки в первую стадию если выявлены проблемы в трехмерной модели
Как и в мире веб разработки, в проектировании должны быть инструменты с разным уровнем абстракции и с разными требованиями к квалификации.
Поэтому, предлагаю фокусироваться не как альтернатива трехмерным редакторам, а как предварительный этап при проектировании. И сразу открывается много направлений развития по уменьшению времени на одну итерацию.
Потому, что дизайн для себя - творческий процесс. Дизайн для кого-то итеративный процесс. А архитектура и интерьеры - очень часто касается многих людей с которыми надо договориться
Тут не учитывается влияние рынка. Чтобы продать, ты должен быть лучше конкурентов.
И одного этого стремления достаточно, чтобы в работе натыкаться на разный набор требований. И приближаться по удобству к мейнстримовым сервисам, навороченным функциям соц. сети N или "быть как apple" :).
Мне как программисту удобно всем отдать одно и тоже проверенное и протестированное. А вот бизнесу это не нужно, как он рынок то завоевывать будет? Он не для этого деньги вкладывает, чтобы быть как все.
Сделать проверку паспорта или генерацию договора, естественно, нельзя, но это и не имеет отношения к авторизации/аутентификации, это же чистой воды бизнес-логика
Так ведь вся статья о том, что клиент не делит авторизацию/аутентификацию на бизнес логику и сервисы. Для него это одна неделимая функция сайта. Поэтому за кажущейся простотой бизнес логики, идет ворох работы по вспомогательным сервисам, тестированию, коммуникациям. И по всему надо обосновать сроки.
Клиенту не нужна бизнес логика в вакууме. Если вы отдадите только бизнес логику даже за 2 дня - клиент вас пошлет с этим неработающим функционалом, это не рабочий функционал который ожидает клиент. Вопрос в том, а заложили ли вы время на расширение бизнес логики до требований заказчика или продали только два дня.
Если резюмировать, то месяца озвучиваемые выше - это не срок реализации бизнес логики, а срок доведения ее до ожиданий клиента. И эти сроки всегда разные, т.к. клиенты разные, опыт разработчиков разный, качество коммуникации разное, подробность и формулировка требований разные, люди и их мотивы разные.
Даже не знаю, где именно тут различие битка от акций компаний. Разве что к акциям все привыкли? И зачем крипту надо сравнивать с «государственные деньгами»?
Что делают когда рубль обваливается?
Правильно, затыкают дыру деньгами из налогов.
Если денег из налогов нет?
То падать может до нуля, государство банкрот и идет за кредитами, объявляет деноминацию
Я не выгораживаю крипту, это молодой инструмент со своими плюсами и минусами.
Но любопытно, что окажется стабильнее распределенный спрос по миру, но сильным влиянием медиа или валюта подверженная локальным кризисам с затыканием дыр за счет денег граждан :)
Думаю тут речь о том, что для создания чего-то нужно иметь справочник в голове.
Как в конструкторе ты должен разложить детали перед собой и понять что ты можешь собрать, как ты это сделаешь и всего ли хватает.
А если ты достаешь по одной детали за раз из коробки (справочника) ты не знаешь что можно создать, как создать и все ли у тебя есть для этого.
Вообще в работе стал замечать, что есть два способа использовать гугл (внешнее онлайн хранилище). В одном случае ты ищешь решения возникших проблем (сценарий снежинки), в другом случае ты хранишь индекс данных (как поисковик) у себя в голове (не нужно помнить все, но нужно знать что есть, как решать, где лежит, как взаимодействует).
Формально все говорят (и программисты и снежинки) зачем запоминать, если все есть в гугле. Но по факту разные сценарии использования.
Поэтому очень важно документацию читать, чтобы проиндексировать ее в голове
Полезная часть сервиса не сам сервис, а контент к которому вы даете интерфейс. Не важно что вы разрабатываете: сайт, приложение, чат бота. В самом начале продумайте какой именно контент окажется в его основе.
У вас есть в команде доктор с достаточным практическим опытом, знания которого и будут перенесены в сервис? А может вы нейронке скормили 100500 книг по медицине и учили ее несколько недель на самых мощных видеокартах?
Даже если вы сами обложитесь книгами, то без должного погружения в медицину, не сможете создать ничего кроме примитивного справочника болезней, а тем более проверить достоверность данных.
Если проанализировать сайты, трафик которых вы решили увести, то в подавляющем большинстве случаев там не только текст, но и информация о том, кто это, якобы, написал. Отсылка к живому профессионалу, которому предлагается поверить.
Вообще, в ИТ очень не хватает профессионалов из других областей, которые стали чуть-чуть программистами. Но в качестве экспертов а не джунов. Чтобы правильно объяснять другим программистам особенности своей профессии и перекладывать свои знания в алгоритмы и данные для будущих экспертных сервисов
Мне кажется не правильно говорить о том что программирование идет в сторону визуализации, а скорее визуальные инструменты идут в сторону программирования.
Но результат в том, что появился новый уровень абстракции, для лучшей передачи дизайнерской задумки вместе с какими либо динамическими элементами для последующей их разработки.
Теперь дизайн может включать в себя заложенную логику поведения сетки, лейаутов, готовых к копированию изингов и ассетов для разработчика.
Это расширение возможностей, а не замена одного на другое
Еще играет роль — пробег клавиатуры. Через год ежедневной работы на клаве с бабочками, клавиши начали залипать. У новых моделей ясно что все будет хорошо. Механизм плохо переносит усталость.
Клавиатуры на macBook Pro 2014 и 2015 годов с аналогичным ежедневным пробегом до сих пор работают как при покупке.
Вопрос в сравнении. Да, по субъективным ощущениям многих бабочка была хуже. Мой личный опыт говорит об этом-же
Вообще, подобная ситуация (если все описанное правда) может возникнуть только в одном случае: отсутствует компетентный тимлид или техдир, способный адекватно оценить реализацию при возникновении разногласий.
В ином случае роляют внерабочие отношения и тут вообще возможна любая дичь :)
Eco-Friendly - это про потребление энергии на реализацию консенсуса. По сравнению с PoW в эфире и биткоине почти все блокчейны, с консенсусом без доказательства работой, считают себя Eco-Friendly
В такой ситуации ничто не поможет :)
Если вести задачи, то совокупные данные по ним могут закрыть потребности в аналитике рентабельности. Оговорка, если вести их
Обычно
Вам нужно измерить рентабельность проекта а не время выполнения каждой задачи, и тут простое суммирование времени выполненных задач к выделенному времени разработчиком. Ведь новые выполненные задачи ровно также влияют на это соотношение, если нет, то кто-то поленился оформить изменения в виде задач. А фильтрация по дате создания - данные для графика внесенных изменений в процессе разработки
Разработчики не роботы, задача сделанная за X весной, не будет сделана за X зимой. Разный эмоциональный фон, разный контекст, разные параллельные проекты. Оценка выполнения конкретной задачи не имеет ценности с точки зрения бизнеса
Изменилось все, поменяйте все невыполненное
Изменилась задача поменяйте эстимейт ее
Изменились приоритеты, будут сделаны сначала другие задачи, а прежние скорее всего останутся но будут отодвинуты
Выполненное - факт созданной работы в рамках выделенного на это времени разработчика. Не важно сколько именно заняла каждая. Важно укладывается ли это в общий таймлайн или надо приоритеты менять.
И есть еще не выполненное, которое тоже хорошо суммируется и показывает будущее с незавершенным проектом в оговоренные с заказчиком сроки :)
Человеческий фактор в оценке своего времени потраченного на задачу точно не лучший показатель для таких расчетов
У вас всегда есть фактическое прошедшее время и реализованый за это время функционал. Чем лучше декомпозированы задачи на старте тем точнее эcтимейт. Где-то время завышено, где-то занижено, но если при декомпозиции подумали о всех мелочах даже на 10 - 15 минут, то в среднем эстимейт при достаточном опыте будет выполняться
Если на старте у вас задачи хорошо декомпозированы. Вынести задачи на таймлайн, то всегда отлично видно как движется разработка и успеваете ли в общие обозначенные рамки рентабельности
Чтобы быть объективными
Дорогие менеджеры и тимлиды заставляющие отмечать время, покажите как выглядит ваша итоговая статистика за пол года и какие выводы она позволяет делать?
Она точно стоит 150 часов рабочего времени дорогостоящих разработчиков и дизайнеров за пол года?
15 минут * 5 участников команды * 20 дней в месяц * 6 месяцев? А это между прочим где-то от 150 000 до полумиллиона за пол года? Такая статистика точно окупается? Нельзя ли как-то автоматизировать сбор данных после выполненных задач и экономить до миллиона в год на квалифицированной команде из 5 человек?
Что люди делают с удовольствием - это закрывают задачи.
Что сложного считать когда какая задача была закрыта? И эстимейтить их?
За десяток лет в отрасли, лично для меня очевидно, что кто-то вместо грамотной декомпозиции и эстимейтов перекладывает работу на разрабов требуя в конце дня еще и время отмечать и следить сколько раз их отрывали от работы с разными вопросами и пожарами.
Разработчик эмоционально переходит в режим оправдания за потраченное время, хотя довольно честно использует все свои ресурсы на работу и старается.
Отмечание времени - это эмоционально сложный процесс. Требующий подведение итога в конце сложного дня. Итог в котором ты должен оценить себя, но так чтобы не показаться плохим разработчиком, но не уменьшить затраченное время и грамотно для "девочек" описать почему потратил несколько часов на баг созданный случайно и решеный одной строкой и которого естественно не было в эстимейте.
Не люблю когда менеджмент начинает попытки ведения статистики не со своего обучения декомпозиции, а с гипотез о том что отмечание времени другими сделает за него его работу
Много раз пробовал сам на своей команде, если нужно тщательно отслеживать прогресс - декомпозиция работает великолепно нужно не бояться даже сотен мелких задач. А все истории с отмечанием времени заканчиваются в тот момент когда на статистику забивают а разраам не показывают реального профита от возложенной на них работы
Дизайн из 90-x :)
В таких инструментах ожидаешь заботу о клиентском восприятии
простота
лаконичность
контроль фокуса внимания
возможность работать с разных устройств при этом иметь одинаковую механику взаимодействия
Кнопочка перевода, возможно, ускоряет работу, но вот дизайн способен снизить нагрузку на восприятие и увеличить время общей работы
Неряшливый набор и группировки, плохая работа с типографикой
Лишние плотные линии
Разные цветовые блоки и яркие пятна
Очень много элементов усложняющих чтение. Вроде мелочь, но при длительной работе накапливается
В 2021 году лично я хотел бы увидеть как рекламируют систему одинаково удобную и на мобильном и на десктопе. Где половину рутины можно сделать еще по пути на работу
Ну как я понимаю, коллекционеры мыслят десятилетиями вперед.
Область новая и в ней не хватает инструментария. Как только появятся инструменты поиска похожих произведений, будут алгоритмы оценки копий и не копий, какие нибудь DAO которые смогут принимать решения считать ли файл копией или новой работой.
Вот тогда все будет приобретать больший смысл. Наверно. Как и с ценными бумагами это вложения в потенциальную выгоду, а не гарантированные проценты в банке.
Обычно решается взятием хеша от файла. Он имеет фиксированную длину, а алгоритм хеширования с большой долей вероятности обеспечивает уникальность его для каждого набора байт (картинка, видео, текст). По крайней мере, крайне сложно изменить объект таким образом чтобы хеш от него остался прежним.
Ссылка, действительно, не дает надежности. Но если ты продаешь твит, то без твиттера он бесполезен.
Базовый алгоритм - взять файл и проверить записи о нем в блокчейне. А не из блокчейна найти где хостится файл.
Надеюсь, набор окажется полезным для моих задач
Вообще, у меня нет проблемы с проектированием и рисованием проекта в том-же SketchUp. Но наблюдаются сложности когда надо обсудить, проговорить и внести коррективы.
Основные задачи:
изменения мог вносить не только я.
обсуждения проходили быстрее с проверкой разных гипотез
результат должен быть красиво оформлен для дальнейшего использования в следующих стадиях
а если можно повесить на стену - вообще шикарно
А в силу того что компьютер и время за ним - тоже ресурс. То, трехмерное моделирование хотелось бы делать уже после. Но и иметь возможность внести правки в первую стадию если выявлены проблемы в трехмерной модели
Как и в мире веб разработки, в проектировании должны быть инструменты с разным уровнем абстракции и с разными требованиями к квалификации.
Поэтому, предлагаю фокусироваться не как альтернатива трехмерным редакторам, а как предварительный этап при проектировании. И сразу открывается много направлений развития по уменьшению времени на одну итерацию.
Потому, что дизайн для себя - творческий процесс. Дизайн для кого-то итеративный процесс. А архитектура и интерьеры - очень часто касается многих людей с которыми надо договориться
В таких штуках важно соотношение стоимости мер противодействия к стоимости получаемой выгоды от нарушения правил
Тут не учитывается влияние рынка. Чтобы продать, ты должен быть лучше конкурентов.
И одного этого стремления достаточно, чтобы в работе натыкаться на разный набор требований. И приближаться по удобству к мейнстримовым сервисам, навороченным функциям соц. сети N или "быть как apple" :).
Мне как программисту удобно всем отдать одно и тоже проверенное и протестированное. А вот бизнесу это не нужно, как он рынок то завоевывать будет? Он не для этого деньги вкладывает, чтобы быть как все.
Так ведь вся статья о том, что клиент не делит авторизацию/аутентификацию на бизнес логику и сервисы. Для него это одна неделимая функция сайта. Поэтому за кажущейся простотой бизнес логики, идет ворох работы по вспомогательным сервисам, тестированию, коммуникациям. И по всему надо обосновать сроки.
Клиенту не нужна бизнес логика в вакууме. Если вы отдадите только бизнес логику даже за 2 дня - клиент вас пошлет с этим неработающим функционалом, это не рабочий функционал который ожидает клиент. Вопрос в том, а заложили ли вы время на расширение бизнес логики до требований заказчика или продали только два дня.
Если резюмировать, то месяца озвучиваемые выше - это не срок реализации бизнес логики, а срок доведения ее до ожиданий клиента. И эти сроки всегда разные, т.к. клиенты разные, опыт разработчиков разный, качество коммуникации разное, подробность и формулировка требований разные, люди и их мотивы разные.
Что делают когда рубль обваливается?
Правильно, затыкают дыру деньгами из налогов.
Если денег из налогов нет?
То падать может до нуля, государство банкрот и идет за кредитами, объявляет деноминацию
Я не выгораживаю крипту, это молодой инструмент со своими плюсами и минусами.
Но любопытно, что окажется стабильнее распределенный спрос по миру, но сильным влиянием медиа или валюта подверженная локальным кризисам с затыканием дыр за счет денег граждан :)
Как в конструкторе ты должен разложить детали перед собой и понять что ты можешь собрать, как ты это сделаешь и всего ли хватает.
А если ты достаешь по одной детали за раз из коробки (справочника) ты не знаешь что можно создать, как создать и все ли у тебя есть для этого.
Вообще в работе стал замечать, что есть два способа использовать гугл (внешнее онлайн хранилище). В одном случае ты ищешь решения возникших проблем (сценарий снежинки), в другом случае ты хранишь индекс данных (как поисковик) у себя в голове (не нужно помнить все, но нужно знать что есть, как решать, где лежит, как взаимодействует).
Формально все говорят (и программисты и снежинки) зачем запоминать, если все есть в гугле. Но по факту разные сценарии использования.
Поэтому очень важно документацию читать, чтобы проиндексировать ее в голове
У вас есть в команде доктор с достаточным практическим опытом, знания которого и будут перенесены в сервис? А может вы нейронке скормили 100500 книг по медицине и учили ее несколько недель на самых мощных видеокартах?
Даже если вы сами обложитесь книгами, то без должного погружения в медицину, не сможете создать ничего кроме примитивного справочника болезней, а тем более проверить достоверность данных.
Если проанализировать сайты, трафик которых вы решили увести, то в подавляющем большинстве случаев там не только текст, но и информация о том, кто это, якобы, написал. Отсылка к живому профессионалу, которому предлагается поверить.
Вообще, в ИТ очень не хватает профессионалов из других областей, которые стали чуть-чуть программистами. Но в качестве экспертов а не джунов. Чтобы правильно объяснять другим программистам особенности своей профессии и перекладывать свои знания в алгоритмы и данные для будущих экспертных сервисов
Но результат в том, что появился новый уровень абстракции, для лучшей передачи дизайнерской задумки вместе с какими либо динамическими элементами для последующей их разработки.
Теперь дизайн может включать в себя заложенную логику поведения сетки, лейаутов, готовых к копированию изингов и ассетов для разработчика.
Это расширение возможностей, а не замена одного на другое
Клавиатуры на macBook Pro 2014 и 2015 годов с аналогичным ежедневным пробегом до сих пор работают как при покупке.
Вопрос в сравнении. Да, по субъективным ощущениям многих бабочка была хуже. Мой личный опыт говорит об этом-же
В ином случае роляют внерабочие отношения и тут вообще возможна любая дичь :)