Ну Петя сам себе злобное буратино, так как должен был в первую очередь поговорить с тем кто поставил задачу о сложившейся ситуации
Перевожу на русский :) Пожаловаться менеджеру на Катю? И что дальше? Наказание Кати? И как бы потом после этого относились в команде к новичку Пете?
Или второй вариант Катю не наказали?
Т. е. идея статьи что так и надо делать? А как тогда должен был поступить Петя (не увидел этого в статье). Петя должен быть наказан, но как он должен поступать в будущем?
Забавно. Так и есть, текст тот же, но воспринимается хуже. Вот она сила дизайна :) Я думал у вас уже готовый проект и статья на хабре это как вариант привлечения первых посетителей. Да и первый коммент про то что, чтобы прочитать идею надо пройти регистрацию. Это сразу отталкивает. Я как пользователь не понимаю что происходит. Я вижу какой-то текст. Нажимаю на ссылку. Ожидаю увидеть его полностью и оценить его полезность для меня, а получаю окно регистрации.
Вообщем можете почитать БМ (я думаю вам это будет близко по духу). Они как раз проповедует максимально быстрый переход от идеи к тестированию и результату. Т.н Тестирование гипотез при выборе ниши. В этом они наверное правы. Если исходить из этого подхода, то вы потратили уже несколько месяцев, а проект по сути еще не готов к тестированию.
Сразу понятно из заголовка что это — Сервис обмена идеями.
Понятно зачем это мне (как пользователю) — творческий тупик, не знаешь чем заняться.
Почему бы не сделать это все сразу на самом сайте?
Остальное по дизайну чисто субъективно:
По цветам мне кажется не очень хорошо выглядит, но это субъективно.
Мало контраста в цветах. Голубой очень спокойный.
Надпись «не знаешь чем заняться творческий тупик», по цвету и композиции сливается с основным текстом.
По композиции текст во второй колонке не понятно как относится к тексту в левой. Воспринимается как однородный текст, за счет того что он находится справа и цвет одинаковый, и становится непонятно почему текст в нем набран меньшим шрифтом.
Цитата выделена синим фоном не понятно зачем. Привлекает к себе внимание, но не несет мне как пользователю информации о проекте.
1. Мое впечатление от сайта. Открыл. 3 секунды смотрел на экран, потом на левое меню, пощелкал по меню. Не понял что это и про что. Закрыл. Забыл.
2. Мне кажется результат того что получилось сейчас, это результат изначально выбранной предпосылки. Из статьи понял что автор выбирал не по принципу чем бы ему хотелось заниматься, а по принципу где бы полегче срубить денег. Правда это было обернуто в красивую обертку «анализа ниш, маркетинговых исследований и т.п.» По факту не понял миссию проекта, не понял для кого он, не понял какую ценность он несет, не увидел какого-то огня, души, личного вклада создателя. Получился средний стандартный сайт, со средним стандартным дизайном.
Потому что принципы современной экономики меня не устраивают. Это грабительская экономика — замаскированный аналог рабства. А принцип справедливой экономики известен давно: каждому по труду. Роберт Оуэн в свое время пытался воплотить данный принцип в жизнь.
Наконец стала понятно идея вашей теории. С этого надо было и начинать статью иначе становится не понятно для реализации какой идеи все это придумано
С практической точки зрение все что вы пытаетесь описать по большей части (там где это необходимо на практике) уже давно реализовано. Посмотрите в сторону ERP систем или хотя бы 1С УПП (или любую другую учетную систему) При этом на практике такие системы существуют параллельно с бухгалтерией и это не вызывает никаких проблем. Там вам и отсутствие двойной записи, и более детальный учет по объектам и т.п.
Позволю высказать своем мнение по поводу вашей статьи
Правило А. В качестве объектов регистрируются однородные сущности.
но нельзя же учитывать в одном ряду вещь, информацию и юридическое право!
Не понятно почему нельзя? Обе эти вещи обладают необходимыми свойствами для учета: право собственности, расчетной стоимостью затрат и участием в конечном продукте. Т.е. допустим для разработки какой-то программы нам пришлось приобрести компьютер и лицензию на определенный софт. В результате упрощенно конечная себестоимость нашей разработанной программы будет включать стоимость компьютера и лицензии.
При этом известно, что Х – Y = Z. В данной ситуации Z – расчетная величина, которую нет необходимости регистрировать в информационной системе в качестве объекта, поскольку она в любой момент может быть вычислена. Никакого Z в реальности нет, это абстракция! Но двойная бухгалтерия, представьте, регистрирует целую группу объектов, относимых к собственному капиталу, причем без данной регистрации просто перестает существовать.
Опять не понятно что вам здесь не нравится? Вы же понимаете что такое баланс? Ничто не берется из неоткуда и никуда не исчезает. Что будет если не регистрировать виртуальную величину Z как вы предлагаете? Как определить за счет какого ресурса образовалась в системе новая сущность?
Правило Б Объект следует идентифицировать: реальный объект должен быть отличим от схожих объектов реальности, а его прототип в информационной системе обладать уникальным идентификатором.
Для чего? Ну если уж так хочется, то в современных учетных системах это возможно реализовать. Чем вам не нравится усредненная система списания? Зачем вам учитывать выбытие каждого отдельного объекта? Технически это реализовать возможно, но это не делают т.к. не имеет практического смысла.
Правило В. Объект обозначается идентификатором и характеризуется признаками.
Это уже давно реализовано в практических системах. Выборку можно сделать не только по иерархии, но и по отдельному признаку из разных иерархий (счетов)
Правило Г. Признаки не могут противоречить друг другу.
Это тоже давно реализовано в практических системах.
Правило Д. и Правило Е
. Непонятно что вы понимаете под понятием объект? Зачем пытаться все свести к объектам реального мира? Какую практическую пользу это несет? С точки зрения бухучета разница в стоимости это тоже объект, с точки зрения реального мира нет. Зачем в бухгалтерии это сделано? Для удобства. Представьте что нет компьютеров и программ. По вашей системе учета чтобы узнать наценку за месяц, надо перебирать все операции и признаки и т.п. и высчитывать что получилось, а в бухгалтерии для этого есть отдельный объект в котором уже есть готовый результат. Аналогично это работает и в компьютерных программах. Намного проще хранить готовую таблицу с наценкой в СУБД из которой брать данные, чем высчитывать это наценку каждый раз заново.
В чем тогда смысл стартапа? Сейчас вообще стало модно все подряд называть словом стартап. Одно дело если команда собралась вокруг какой-то идеи продукта и эта идея объединила людей. Другое дело когда идея заключается не в продукте, а в том на чем бы заработать денег, какие потребности клиентов удовлетворить. В чем тогда отличие стартапа от просто команды людей нанятых (инвестором) чтобы удовлетворить какие-то потребности рынка?
Я имел ввиду не гарфик. Как я понял автор хотел сказать, что стоит ориентироваться не на продукт, а на клиента. В первом случае у стартапа есть какая-то идея, которой они горят. Они на основе этой идеи делают продукт, а потом у этого продукта появляется аудитория (или не появляется). И задача команды в этом случае сделать продукт как можно лучше. Да может случится что продукт опережает свое время, либо он нужен очень узкой аудитории и т.п. Иногда продукт настолько инновационный, что для того чтобы он стал популярен аудитории требуется прогнутся под продукт. Допустим какой-то новый интерфейс управления. Люди не очень любят учится чему-то новому. Зато освоив и разобравшись они понимают преимущество продукта и не хотят возвращаться к старому.
Во втором же случае стартап должен отталкиваться от потребностей клиента. А клиент порой сам не знает что он хочет. При этом подходе нельзя «изобрести» что-то революционно новое.
На мой взгляд разница в подходах кардинальная. В первом подходе: о у нас есть классная идея, она нам нравится и мы ее реализуем, во втором: на чем бы можно заработать денег? о вроде сейчас здесь тренд это модно/востребовано давайте займемся этим.
На мой взгляд спорная статья. Если рассматривать стартап только как возможность заработать денег (да еще и по быстрому), то пожалуй автор прав. Все таки я думаю что в стартапе участники должны ориентироваться на свою идею и гореть этой идеей, а не «прогибаться» под клиента.
Я вашу позицию понял. Вы для себя четко разделяете работу и жизнь/отдых. Но ведь вы допускаете что есть люди для кого работа не только средства получить деньги, но и еще любимое занятие?
>>Ага, от того, что вы составляете списки, то что надо автоматически становится тем что хочется.
Просто это еще один шаг к осознанности. Кто-то сразу может понять что к чему, кому то надо сначала записать, чтобы потом осмыслить.
>>Прикольно конечно говорить шефу что этот стремный баг ты не исправил, потому что этот процесс в твоих глазах имеет низкий балл привлекательности.
Если тебя напрягает постоянно исправлять стремные баги есть два выхода:
1. Осознать это и попытаться что-то изменить. Вплоть до того, чтобы заняться чем то другим, тем что тебе нравиться.
2. Убедить себя что по другому никак. Все пашут, все делают то что надо и вообще жизнь дерьмо.
Очень здравая идея. Единственное можно еще кое что усовершенствовать.
1. Выставление оценок задачам. Я думаю этот пункт лишний. Т.к. настроение может меняться сейчас хочется делать больше эту задачу, через 3 часа другую. Либо опять приходим к минусам GTD, когда надо будет с какой-то периодичностью переписывать оценки задачам, либо привязываем себя к ранее данным оценкам и как следствие загоняем в рамки.
2. Осознанный отказ от задачи. Иногда это бывает трудно, да и зачем себя насиловать? Часто нежелание браться за задачу может быть связно не с ее ненужностью, а с недостатком ресурсов на данном этапе. Завтра, через неделю эти ресурсы могут появится и задача вновь станет актуальной и желанной. Поэтому не отказ, а откладывание, если дело только в отсутствии ресурсов.
3. Разложение на подзадачи с последующей оценкой подзадач. В результате вы складываете оценки по подзадачам и делаете вывод по мотивации. Это же очевидный костыль из GTD. По моему необязательно делать задачу от начала и до конца (причину см в п.2 про ресурсы). К примеру у вас есть задача в общем привлекательная из 3-х этапов: первый и третий привлекательны, второй нет. Причина недостаточность ресурсов для второго этапа (отсутствие знаний как это сделать к примеру). Можно сделать первый этап и отложить задачу до появления ресурсов, а можно по вашей методике оценить ее как не привлекательную и «выбросить в корзину». А через неделю, например, вы познакомились с человеком, который хорошо разбирается в пункте 2. С его помощью вы бы могли преодолеть второй этап, а вы задачу уже выкинули.
3.
Тема конечно интересная но не для всех. Можно сказать проще делай только то что нравиться. Т.е. иногда получается так захотелось сейчас заняться прошивкой, скачал. А завтра уже не интересно это, ну и фиг с ней. Не надо оглядываться в прошлое и пытаться доделать все что начал, если сейчас тебе это уже не интересно. Проще говоря необязательно все делать с начала и до конца. Можно начать и бросить в любой момент, если желание уже пропало. Лучше переключиться на то, что сейчас действительно прет. Это как байка про виноград. Вот лежит в миске виноград сверху хорошие ягоды, а с низу мятые. Можно конечно силой воли заставить себя съесть все до одной, но зачем?
Не понял что хотел сказать автор статьи. Да проблема существует, но есть стандартные пути ее решения.
1. Сначала написать ТЗ. Потом «строго» делать по ТЗ. Ответственность большей частью будет на заказчике. Упустил, не указал в ТЗ сам виноват.
2. Если заказчик не хочет/не может составить ТЗ. Agile/Srum/попросту почасовка. Делаем и походу разбираемся в том, что надо сделать :) Все переделки опять же оплачиваются заказчиком.
3. Если заказчика не устраивает, ни первое ни второе, то может не стоит связываться с таким заказчиком?
Какие конкретно в данном случае договоренности нарушил Петя?
Перевожу на русский :) Пожаловаться менеджеру на Катю? И что дальше? Наказание Кати? И как бы потом после этого относились в команде к новичку Пете?
Или второй вариант Катю не наказали?
Вообщем можете почитать БМ (я думаю вам это будет близко по духу). Они как раз проповедует максимально быстрый переход от идеи к тестированию и результату. Т.н Тестирование гипотез при выборе ниши. В этом они наверное правы. Если исходить из этого подхода, то вы потратили уже несколько месяцев, а проект по сути еще не готов к тестированию.
Сразу понятно из заголовка что это — Сервис обмена идеями.
Понятно зачем это мне (как пользователю) — творческий тупик, не знаешь чем заняться.
Почему бы не сделать это все сразу на самом сайте?
Остальное по дизайну чисто субъективно:
1. Мое впечатление от сайта. Открыл. 3 секунды смотрел на экран, потом на левое меню, пощелкал по меню. Не понял что это и про что. Закрыл. Забыл.
2. Мне кажется результат того что получилось сейчас, это результат изначально выбранной предпосылки. Из статьи понял что автор выбирал не по принципу чем бы ему хотелось заниматься, а по принципу где бы полегче срубить денег. Правда это было обернуто в красивую обертку «анализа ниш, маркетинговых исследований и т.п.» По факту не понял миссию проекта, не понял для кого он, не понял какую ценность он несет, не увидел какого-то огня, души, личного вклада создателя. Получился средний стандартный сайт, со средним стандартным дизайном.
Да простит меня автор за критику
Наконец стала понятно идея вашей теории. С этого надо было и начинать статью иначе становится не понятно для реализации какой идеи все это придумано
Не понятно почему нельзя? Обе эти вещи обладают необходимыми свойствами для учета: право собственности, расчетной стоимостью затрат и участием в конечном продукте. Т.е. допустим для разработки какой-то программы нам пришлось приобрести компьютер и лицензию на определенный софт. В результате упрощенно конечная себестоимость нашей разработанной программы будет включать стоимость компьютера и лицензии.
Опять не понятно что вам здесь не нравится? Вы же понимаете что такое баланс? Ничто не берется из неоткуда и никуда не исчезает. Что будет если не регистрировать виртуальную величину Z как вы предлагаете? Как определить за счет какого ресурса образовалась в системе новая сущность?
Для чего? Ну если уж так хочется, то в современных учетных системах это возможно реализовать. Чем вам не нравится усредненная система списания? Зачем вам учитывать выбытие каждого отдельного объекта? Технически это реализовать возможно, но это не делают т.к. не имеет практического смысла.
Это уже давно реализовано в практических системах. Выборку можно сделать не только по иерархии, но и по отдельному признаку из разных иерархий (счетов)
Это тоже давно реализовано в практических системах.
. Непонятно что вы понимаете под понятием объект? Зачем пытаться все свести к объектам реального мира? Какую практическую пользу это несет? С точки зрения бухучета разница в стоимости это тоже объект, с точки зрения реального мира нет. Зачем в бухгалтерии это сделано? Для удобства. Представьте что нет компьютеров и программ. По вашей системе учета чтобы узнать наценку за месяц, надо перебирать все операции и признаки и т.п. и высчитывать что получилось, а в бухгалтерии для этого есть отдельный объект в котором уже есть готовый результат. Аналогично это работает и в компьютерных программах. Намного проще хранить готовую таблицу с наценкой в СУБД из которой брать данные, чем высчитывать это наценку каждый раз заново.
Во втором же случае стартап должен отталкиваться от потребностей клиента. А клиент порой сам не знает что он хочет. При этом подходе нельзя «изобрести» что-то революционно новое.
На мой взгляд разница в подходах кардинальная. В первом подходе: о у нас есть классная идея, она нам нравится и мы ее реализуем, во втором: на чем бы можно заработать денег? о вроде сейчас здесь тренд это модно/востребовано давайте займемся этим.
Просто это еще один шаг к осознанности. Кто-то сразу может понять что к чему, кому то надо сначала записать, чтобы потом осмыслить.
>>Прикольно конечно говорить шефу что этот стремный баг ты не исправил, потому что этот процесс в твоих глазах имеет низкий балл привлекательности.
Если тебя напрягает постоянно исправлять стремные баги есть два выхода:
1. Осознать это и попытаться что-то изменить. Вплоть до того, чтобы заняться чем то другим, тем что тебе нравиться.
2. Убедить себя что по другому никак. Все пашут, все делают то что надо и вообще жизнь дерьмо.
1.
Выставление оценок задачам.Я думаю этот пункт лишний. Т.к. настроение может меняться сейчас хочется делать больше эту задачу, через 3 часа другую. Либо опять приходим к минусам GTD, когда надо будет с какой-то периодичностью переписывать оценки задачам, либо привязываем себя к ранее данным оценкам и как следствие загоняем в рамки.2.
Осознанный отказ от задачи.Иногда это бывает трудно, да и зачем себя насиловать? Часто нежелание браться за задачу может быть связно не с ее ненужностью, а с недостатком ресурсов на данном этапе. Завтра, через неделю эти ресурсы могут появится и задача вновь станет актуальной и желанной. Поэтому не отказ, а откладывание, если дело только в отсутствии ресурсов.3.
Разложение на подзадачи с последующей оценкой подзадач.В результате вы складываете оценки по подзадачам и делаете вывод по мотивации. Это же очевидный костыль из GTD. По моему необязательно делать задачу от начала и до конца (причину см в п.2 про ресурсы). К примеру у вас есть задача в общем привлекательная из 3-х этапов: первый и третий привлекательны, второй нет. Причина недостаточность ресурсов для второго этапа (отсутствие знаний как это сделать к примеру). Можно сделать первый этап и отложить задачу до появления ресурсов, а можно по вашей методике оценить ее как не привлекательную и «выбросить в корзину». А через неделю, например, вы познакомились с человеком, который хорошо разбирается в пункте 2. С его помощью вы бы могли преодолеть второй этап, а вы задачу уже выкинули.3.
1. Сначала написать ТЗ. Потом «строго» делать по ТЗ. Ответственность большей частью будет на заказчике. Упустил, не указал в ТЗ сам виноват.
2. Если заказчик не хочет/не может составить ТЗ. Agile/Srum/попросту почасовка. Делаем и походу разбираемся в том, что надо сделать :) Все переделки опять же оплачиваются заказчиком.
3. Если заказчика не устраивает, ни первое ни второе, то может не стоит связываться с таким заказчиком?