Comments 17
Статья напомнила мне видео на канале Vsauce, в ютубе.
UFO just landed and posted this here
Только мне кажется что именно для таких статей создавался http://megamozg.ru/?
Просто в эдисоне этом понимают, что на мегамозге их рекламу никто читать не будет. А вообще за «случайное» размещение рекламы на хабре надо бы банить на пару месяцев.
У них корпоративный блог, а для корп. блогов правила немного другие.
Да, верно. Но по хорошему заголовок таких постов должен начинаться с «Реклама: Основные законы...», чтобы не обманывать читателей. Но проблема ведь в том, что без такого обмана (это ещё, кажется, называется «джинсой») число прочитавших статью будет намного меньше. Так что всё честно: читателей обманывают насчёт содержимого статьи, а они в ответ кидают в корпоративный блог помидорами.
За помидоры вам еще и карму сольют — мне два человека после поста заминусовали. Корпоративный дух. Команда крепкая, видимо.
Ну где-где реклама в статье-то? Там вообще ничего о фирме не нашел, кроме первой строки. Так можно вообще можно любую статью в корпоративном блоге называть рекламой (гугл описывает разработку хрома — реклама, пишет о поиск — реклама и т.д.). И, ИМХО, не стоит грешить на команду, я заметил, на хабре вообще не любят кидание помидорами в комментах, если статья совсем уж не провальная.
Рекламы как таковой нет. Упоминание компании в корпоративном блоге один раз — это нормально.
Но статья начинается многообещающе: «к нам обращаются многие за помощью и вообще...» и я, например, ожидал, как минимум, примеров из опыта компании с собственными выводами.
На деле оказалось что компания просто наняла копирайтера, который надергал цитат из книжек по менеджменту.
Хочется заметить, что книжек на свете много и некоторые противоречат друг другу (а некоторые зачастую и самим себе). Про применимость к конкретным случаям я уж вообще молчу.
Если бы статья была в форме «теория -> как это в нашей компании», то было бы гораздо больше смысла.
Читать в очередной раз о законе Брукса в теории лично мне было разочарованием.
И, опять же, если уж ввели правило «хабр — для кода, мегамозг — для статей о менеджменте», то давайте уважать правила. А то получается что интересные статьи закрывают или переносят на гиктаймс, а такие как эта — оставляют. Лично у меня после этого к компании Эдисон отношение — не очень хорошее.
Компании тоже можно понять — корпоративный блог надо поддерживать. Если он бесплатный, то в него надо сколько-то статей в год выдавать. Если платный — то просто так платить за него не хочется. Писать технари отказываются, а девочка-копирайтер умеет только про менеджмент.
Но статья начинается многообещающе: «к нам обращаются многие за помощью и вообще...» и я, например, ожидал, как минимум, примеров из опыта компании с собственными выводами.
На деле оказалось что компания просто наняла копирайтера, который надергал цитат из книжек по менеджменту.
Хочется заметить, что книжек на свете много и некоторые противоречат друг другу (а некоторые зачастую и самим себе). Про применимость к конкретным случаям я уж вообще молчу.
Если бы статья была в форме «теория -> как это в нашей компании», то было бы гораздо больше смысла.
Читать в очередной раз о законе Брукса в теории лично мне было разочарованием.
И, опять же, если уж ввели правило «хабр — для кода, мегамозг — для статей о менеджменте», то давайте уважать правила. А то получается что интересные статьи закрывают или переносят на гиктаймс, а такие как эта — оставляют. Лично у меня после этого к компании Эдисон отношение — не очень хорошее.
Компании тоже можно понять — корпоративный блог надо поддерживать. Если он бесплатный, то в него надо сколько-то статей в год выдавать. Если платный — то просто так платить за него не хочется. Писать технари отказываются, а девочка-копирайтер умеет только про менеджмент.
Мне тоже два минуса прилетело :)
Ну все-таки грамотный подбор команды касается всех программистов в команде, а не только одного менеджера/директора. Особенно если в команде используется Scrum и т.п. методологии. Хотя я не менеджер, а программист (ну ладно, на данный момент не менеджер) мне почитать было довольно интересно. ИМХО, для team lead'ов и senior программистов статья должна быть интересной, поэтому ей вполне место на хабре (ИМХО, конечно).
оптимизм относительно даты выполнения задачи дает возможность осуществить работу раньше, чем при пессимистичной оценке сроков. Но общее время выполнения проекта оптимистом окажется дольше, чем у пессимиста.
Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?
Срок дедлайна может быть важнее предполагаемого времени завершения проекта
Чо?
Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?
Подозреваю, что можно осуществить работу раньше работая по 20 часов в день и выходные, а потом взять на пару недель отгулы, а можно спокойно завершить на неделю позже, но без аврального режима.
Как можно осуществить работу раньше, но при этом с большим общим временем выполнения?
Я понял так, что оптимист и пессимист делают работу за одно время, но дают разные предварительные оценки сроков
На картинке неплохая команда. Но что насчет этой команды?
Sign up to leave a comment.
Основные законы создания команд разработчиков