Development Management
Project management
Product Management
Comments 27
+3
Я разделяю вашу точку зрения, но если бы не разделял, то этой статьей вы бы меня не переубедили.
0
Честно говоря, в жизни иногда даже самого себя приходится в этом переубеждать заново.
Здесь лучший аргумент — собственные ограниченные ресурсы. Ну и опыт, конечно.
-3
Стопроцентным не бывает даже спирт

Бывает, кстати, это т.н. абсолютный спирт. И мне не понравилось, что вы обращаетесь ко мне на «ты». Хотя в целом, безотносительно особенностей написания, в статье есть здравое зерно.
0
Не хотел показаться грубым. Писал как себе. Если что, приношу извинения.
-2
Да всё в порядке. Честно сказать, я просто немного придираюсь на основе своих тараканов. Пишите еще :)
0
Из вежливости, которая подразумевает, в частности, дистанцию, которую сокращают только по приглашения и взаимному желанию.
0
Вежливость — понятно, дистанция — понятно, непонятно, как связаны между собой вежливость с дистанцией и «вы». «Вы» означает 2 и более человек. Им нравится это? И почему «ты» — это плохо?
0
Простите за любопытство, а вы русский язык по книгам изучали или по форумам?
0
дистанцию, которую сокращают только по приглашения и взаимному желанию

Благодарю, вы поняли меня абсолютно точно. Для меня «ты» — обращение, допустимое от очень немногих друзей и близких, а «вы» — от всех остальных, так я и сам общаюсь в обычной жизни, когда я слышу «ты» от незнакомого мне человека, мне это доставляет дискомфорт, потому, что это сокращение дистанции, которого я вовсе не позволял. Или, допустим, если какая-то статья или реклама начинается с обращения «Друзья, мы...» — но ведь мы не друзья, вот в чем дело.

Понятное дело, что автор конкретной статьи не имел целью оскорбить лично меня, но и я не имел цели оскорбить его своим ответом, я просто выразил свое мнение по поводу статьи — что понравилось, а что нет, так что я искренне не понимаю, откуда минусы.
0
«Друзья, мы» — понятно.
Являешься ли ты «вы»?
Мне интересно, как думают люди, кому нравится «вы». Может быть, они знают то, чего я не знаю.
0
Предполагается, что будет сделано нужное и в нужном качестве (можно трактовать минимальное и в минимальном качестве), а вылизывать потом, когда продукт взлетит.
А в реальности этими соображениями могут оправдывать некомпетентность и создание чего то на отвали. Где грань, вот в чем вопрос.
0
Некомпетентность, к сожалению, практически все можно оправдать.
Грань в любом случае искать придётся. Перегиб ни в одну сторону не нужен.
0
Что делать с ошибками? На какой стадии проекта писать их обработку?
0
Видимо у вас накипело. Некоторые программисты действительно склонны к перфекционизму, особенно фанатеющие от своего дела. Так что брать на проект таких фанатиков нужно очень осторожно и четким пониманием их роли
0
С юристами-перфекционистами работать тоже очень интересно ;)
0

Про закон Парето (20/80) — он конечно работает, но загвоздка в том, что усилилий все равно надо затратить 100%

0
20% зависят от остальных 80%
Например регистрацией пользуются 1 раз, а авторизацией много раз, но смысла в авторизации без регистрации мало.
0
Я бы не стал относить регистрацию к 80%.
К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
0
Ссылка из вашей статьи ведет на страничку в Википедии, где эта ситуация объясняется («Критика принципа Парето»). Можно привести в качестве примера строительство дома, где на проект, коммуникации, фундамент и п.р. тратятся огромные ресурсы, но доход приносит только продажа помещений.
Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
0
Думаю, к закону Парето тоже стоит применять закон Парето :)
Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
0
Чтобы перестать делать идеальное решение, программисту нужно научиться мыслить нуждами бизнеса. Очень часто в бизнесе надо проверить нужно ли что-то вообще кому-то, поэтому разработка идеально работающей функции не имеет смысла, ведь она может оказаться никому не нужна, поэтому следует делать Proof of Concept в виде некоего MVP. Причем этим MVP может быть даже обычная кнопка в уже работающей и запущенной программе.
Плюс ко всему, достаточно сложную систему практически невозможно построить сразу с нуля, большинство сложных и хорошо работающих системы возникают, эволюционируя из более простых.
0
Дополню немного: «Если есть два варианта — лепи чекбокс!» :) Никогда не решай за юзера, ЧТО он может захотеть, всегда давай ему выбор. Особенно если решил «выпилить» старый функционал и «намодернячить» что-то (как тебе кажется) более удобное.

Постоянно взаимодействовать с непосредственным юзером. Не его начальником или «властелином всея ИТ», а только с теми, кто непосредственно будет делать работу.

Валидаторы засунь в зад! В смысле, в последнюю очередь. Не раздражай юзера тем, что в поле ввода ограничил длину или набор символов — там может быть обычная скопипащеная строка, которую он просто отредактирует. Влезая в сам процесс редакции, ты бесишь всех.

По поводу команды… спорный вопрос. КАЖДЫЙ из вас — непризнанный гений. Но десять гениев в команде — это просто сборище упрямых баранов, ведущее проект в никуда. Решения должен принимать ОДИН, выслушав мнение остальных. Он же — вести главную разработку. Особенно убивают проект «космические архитекторы», высасывающие из известного пальца маргинальные случаи и превращающие простую задачу в «гиперконфигурируемый всемогутер» примерно на миллион человекочасов. Особенно этим страдает MS.

Ещё в моей практике помогает подход «сразу же бросаемся кодировать». Как ни странно для яйцеголовых любителей порассуждать о том, какие они умные в своих академических подходах, именно непосредственное влезание в «а как это будет в коде» сразу же выявляет интересные аспекты, невидимые на бумаге. Разумеется, этот код сразу на выброс, но вернувшись от него к бумаге, чётче понимаешь, что и как надо проектировать. Это как в известном принципе «хорошая программа должна быть написана дважды».
Only those users with full accounts are able to leave comments. , please.