Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Я разделяю вашу точку зрения, но если бы не разделял, то этой статьей вы бы меня не переубедили.
33% против 69% это интересный показатель.
Стопроцентным не бывает даже спирт
Бывает, кстати, это т.н. абсолютный спирт. И мне не понравилось, что вы обращаетесь ко мне на «ты». Хотя в целом, безотносительно особенностей написания, в статье есть здравое зерно.
Не хотел показаться грубым. Писал как себе. Если что, приношу извинения.
Да всё в порядке. Честно сказать, я просто немного придираюсь на основе своих тараканов. Пишите еще :)
Почему одному человеку говорят «вы»?
Вежливость — понятно, дистанция — понятно, непонятно, как связаны между собой вежливость с дистанцией и «вы». «Вы» означает 2 и более человек. Им нравится это? И почему «ты» — это плохо?
дистанцию, которую сокращают только по приглашения и взаимному желанию
Благодарю, вы поняли меня абсолютно точно. Для меня «ты» — обращение, допустимое от очень немногих друзей и близких, а «вы» — от всех остальных, так я и сам общаюсь в обычной жизни, когда я слышу «ты» от незнакомого мне человека, мне это доставляет дискомфорт, потому, что это сокращение дистанции, которого я вовсе не позволял. Или, допустим, если какая-то статья или реклама начинается с обращения «Друзья, мы...» — но ведь мы не друзья, вот в чем дело.
Понятное дело, что автор конкретной статьи не имел целью оскорбить лично меня, но и я не имел цели оскорбить его своим ответом, я просто выразил свое мнение по поводу статьи — что понравилось, а что нет, так что я искренне не понимаю, откуда минусы.
Что делать с ошибками? На какой стадии проекта писать их обработку?
Видимо у вас накипело. Некоторые программисты действительно склонны к перфекционизму, особенно фанатеющие от своего дела. Так что брать на проект таких фанатиков нужно очень осторожно и четким пониманием их роли
Про закон Парето (20/80) — он конечно работает, но загвоздка в том, что усилилий все равно надо затратить 100%
в каком смысле?
Я бы не стал относить регистрацию к 80%.
К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
Ссылка из вашей статьи ведет на страничку в Википедии, где эта ситуация объясняется («Критика принципа Парето»). Можно привести в качестве примера строительство дома, где на проект, коммуникации, фундамент и п.р. тратятся огромные ресурсы, но доход приносит только продажа помещений.
Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
Думаю, к закону Парето тоже стоит применять закон Парето :)
Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
Чтобы перестать делать идеальное решение, программисту нужно научиться мыслить нуждами бизнеса. Очень часто в бизнесе надо проверить нужно ли что-то вообще кому-то, поэтому разработка идеально работающей функции не имеет смысла, ведь она может оказаться никому не нужна, поэтому следует делать Proof of Concept в виде некоего MVP. Причем этим MVP может быть даже обычная кнопка в уже работающей и запущенной программе.
Плюс ко всему, достаточно сложную систему практически невозможно построить сразу с нуля, большинство сложных и хорошо работающих системы возникают, эволюционируя из более простых.
Плюс ко всему, достаточно сложную систему практически невозможно построить сразу с нуля, большинство сложных и хорошо работающих системы возникают, эволюционируя из более простых.
Мотивирует =) Спасибо!
Дополню немного: «Если есть два варианта — лепи чекбокс!» :) Никогда не решай за юзера, ЧТО он может захотеть, всегда давай ему выбор. Особенно если решил «выпилить» старый функционал и «намодернячить» что-то (как тебе кажется) более удобное.
Постоянно взаимодействовать с непосредственным юзером. Не его начальником или «властелином всея ИТ», а только с теми, кто непосредственно будет делать работу.
Валидаторы засунь в зад! В смысле, в последнюю очередь. Не раздражай юзера тем, что в поле ввода ограничил длину или набор символов — там может быть обычная скопипащеная строка, которую он просто отредактирует. Влезая в сам процесс редакции, ты бесишь всех.
По поводу команды… спорный вопрос. КАЖДЫЙ из вас — непризнанный гений. Но десять гениев в команде — это просто сборище упрямых баранов, ведущее проект в никуда. Решения должен принимать ОДИН, выслушав мнение остальных. Он же — вести главную разработку. Особенно убивают проект «космические архитекторы», высасывающие из известного пальца маргинальные случаи и превращающие простую задачу в «гиперконфигурируемый всемогутер» примерно на миллион человекочасов. Особенно этим страдает MS.
Ещё в моей практике помогает подход «сразу же бросаемся кодировать». Как ни странно для яйцеголовых любителей порассуждать о том, какие они умные в своих академических подходах, именно непосредственное влезание в «а как это будет в коде» сразу же выявляет интересные аспекты, невидимые на бумаге. Разумеется, этот код сразу на выброс, но вернувшись от него к бумаге, чётче понимаешь, что и как надо проектировать. Это как в известном принципе «хорошая программа должна быть написана дважды».
Постоянно взаимодействовать с непосредственным юзером. Не его начальником или «властелином всея ИТ», а только с теми, кто непосредственно будет делать работу.
Валидаторы засунь в зад! В смысле, в последнюю очередь. Не раздражай юзера тем, что в поле ввода ограничил длину или набор символов — там может быть обычная скопипащеная строка, которую он просто отредактирует. Влезая в сам процесс редакции, ты бесишь всех.
По поводу команды… спорный вопрос. КАЖДЫЙ из вас — непризнанный гений. Но десять гениев в команде — это просто сборище упрямых баранов, ведущее проект в никуда. Решения должен принимать ОДИН, выслушав мнение остальных. Он же — вести главную разработку. Особенно убивают проект «космические архитекторы», высасывающие из известного пальца маргинальные случаи и превращающие простую задачу в «гиперконфигурируемый всемогутер» примерно на миллион человекочасов. Особенно этим страдает MS.
Ещё в моей практике помогает подход «сразу же бросаемся кодировать». Как ни странно для яйцеголовых любителей порассуждать о том, какие они умные в своих академических подходах, именно непосредственное влезание в «а как это будет в коде» сразу же выявляет интересные аспекты, невидимые на бумаге. Разумеется, этот код сразу на выброс, но вернувшись от него к бумаге, чётче понимаешь, что и как надо проектировать. Это как в известном принципе «хорошая программа должна быть написана дважды».
Часто бывает так, что одно «не идеальное» решение приводит к череде других «не идеальных», и вот вы уже на проекте, являющемся «далеко не идеальным»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему тебе не нужно идеальное решение