Pull to refresh
12
0
Анатолий Юдов @misato

Пользователь

Send message
Это уже вопрос организации производственного процесса. Ситуация, когда разработчика постоянно «дёргают» — вообще неправильная, такого быть не должно.
Вопрос о том, что вообще считать «фактически затраченным временем» при разработке сайта — это не пустая болтовня, а действительно интересная тема, размышляя над которой можно далеко зайти. Вот если человек занимался задачей два рабочих дня, то чистого времени у него набежит часов 10-12, а фактического, рабочего — 16 часов. А то ведь так можно дойти до того, чтобы учитывать только то время, пока человек нажимает на кнопки — в остальное-то время код не наращивается, значит и работа не совершается, да?

Если речь идёт о программистах, работающих на полный рабочий день, то, на мой взгляд, для них считать точные часы не имеет смысла. Хороший программист будет работать и в нерабочее время, потому что его мозг продолжит решать задачи. Эффективность этой работы подвержена циклическим колебаниям, зависит от потока и прочей ерунды. Сводить это к учётным минутам — просто бессмыслица. Отметили долю рабочего дня, потраченного на проект, и достаточно. А что там клиент оплачивает — это вообще маркетинговый вопрос, в общем случае может быть вообще с себестоимостью разработки не связан.
Вопрос в том, нужен ли точный учёт времени на вашем производстве. Если речь идёт, например, о разработке ПО, то скорее всего не нужен.
Стадо коров на фоне ракеты сразу напомнило Cowboy Bebop или Firefly ;)
Смысл проделанных ритуальных действий — в отказе от Scrum. Проблема была в том, что вы работали по скраму. Как только перестали — стало хорошо.
Человек не имеет возможности близко знакомиться со всеми на свете теориями. Это неправильно, когда краткая выжимка, по сути дела, реферат, не даёт никакого представления о работе. Да, статья рисует яркие картинки и образы, но ведь это не суть. Чтобы до этого всего додуматься (коммунизм, автоматизация), не нужно быть семи пядей во лбу.

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

Гораздо важнее подумать, а нужно ли это человечеству вообще, жить в таком эффективном муравейнике. Каково это будет, существовать в такой структуре? Сможет ли наше общество вообще прийти к такой системе, или это будет уже совсем другое общество, противное нашей нынешней природе?

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

Что такое «ресурсная экономика»? Почему он решил, что она лучше денежной? Каким образом будет организовано движение товаров и услуг, если не будет денег? Какой учёный будет принимать решение о том, что кому выделить мяса, а кому не выделить?

Почему он считает что «научный анализ» при принятии решений по части городской жизни — это лучше, чем решение представительного органа?

И вообще, что значит «лучше»? Эффективнее, рациональнее для человечества как вида? Возможно. Лучше для индивида? Неизвестно.
Поясните, почему блог — это упрощение форума? И почему это участие в форуме требует больше мозгов? В чём принципиальная разница в требованиях к мозгам?
Друзья, огромное достоинство WYSIWYG — это легкость редактирования уже размещенных материалов. Даже если человек является специалистом, знает HTML и всё остальное, ему проще ткнуть мышкой в нужное слово и исправить, чем ковыряться в HTML-коде.

Проблема с самодеятельностью секретарши Зины должна решаться ограничением возможностей редактора, ту всё верно говорят.
Это никакая не методология, а просто способ пользоваться жирой.

У нас тоже примерно так принято, это нетрудно.

Чего не стоит делать?

1. Не браться за дело, если пока ещё не знаешь как его делать (перекликается с советом не использовать незнакомую технологию).

2. Не браться за дело, если знаешь что на него нет времени.

Как стоит поступать?

3. Каждый день просыпаться утром и до вечера делать что-нибудь полезное (читай — рабочее).

4. Писать отчёты, вести лог.

5. Отдыхать в выходные дни с друзьями.

6. Если есть свободное время в будний день — изучать новые технологии, так чтобы реже отказываться согласно п.1. и почаще отказываться согласно п.2. :)
Мне всё-таки думается, что без обобщающего раздела ТЗ не обойтись. «Кому нужны будут эти разделы? Почему вообще именно эта функциональность?» — об этом нужно подумать и написать.

Ни одно техническое задание не может описать результат полностью, в мелочах, потому что для этого нужно проделать всю работу, которую задание описывает. Чтобы исполнители могли принимать решения о мелочах, о деталях, им нужно чувствовать назначение всех составляющих элементов. Когда придумаете эти обобщающие разделы, может быть и предполагаемая структура разделов покажется неверной.
Нечто подобное я задумывал сделать лет эдак пять-шесть назад, однако сам был слишком молод и бестолков :) В моих терминах это называлось «артель», и суть сводилась к тому что каждый специалист экономит время и силы на сопутствующую деятельность (поиск заказов, поддержка собственного сайта, договора, налоги и другая бюрократия) — то есть, примерно как и у вас.

Сейчас мне видится тут один ключевой недостаток. В проекте должен быть администратор, который будет, как минимум, единолично управлять ресурсами. Демократия тут работать не будет, потому что вопрос распределения гешефта — это игра с нулевой суммой. Сейчас я думаю, что эту роль должен выполнять кто-то со стороны заказчика, т.е., мы фактически включаем его в команду в роли одного из руководителей.

Есть недостатки и менее существенные. В первую очередь я сюда отношу инфраструктуру проекта, которую всякий раз надо создавать заново, что противоречит самим основам проектной деятельности. Во-вторых — банальная «сработанность» команды.

Однако в эту сторону имеет смысл думать и работать, чтобы иметь возможность гибко собирать работоспособный коллектив для решения конкретной задачи, сохраняя при этом качество.
50 лет назад городской образ жизни уже был повсеместно принят и понятен — в СССР уже даже почти спутник запускали. Я думаю, что в цитате говорилось о более ранней эпохе, когда сельское население только-только начинало переселяться в города, что было связано с развитием ремесленничества. То есть, смысл в том, что для человека считалось нормальным кормить себя самому. Полагаться только на то, что у тебя будут деньги или вещи, которые ты обменяешь на еду, считалось довольно рискованным. Со временем этот риск стал вполне приемлимым.
Так и теперь, считается что постоянная работа и зарплата — это твой огород и твой скот, а стартап и бизнес — это ремесло и город. В первом случае у тебя всегда есть крыша над головой и еда, а во втором надо постоянно идти вперёд, иначе есть будет нечего.
Да, я уже сообразил, спасибо!
Мне кажется, что такое являение как веб-дизайн в принципе массово существует только в нашей стране. В других странах под этим понимают несколько другие вещи.

Там это либо простая самоделка, своими силами, чтобы контент был, либо в составе конкретной рекламной кампании, сделанное рекламным агентством как один из необходимых инструментов привлечения/распространения/т.п.

У нас же считается что сайт — это некая отдельная вещь в себе. Или например логотип. Или визитка. Появились деньжата — надо чтобы было круто, наступили времена похуже — закрываем это всё. Как потёмкинская деревня.
действительно, и этот вопрос тоже не праздный!
Адаптированный перевод SW-CMM и стандарт ГОСТ Р ИСО 12207 - в них есть вся основа для управления разработкой любого софта. Зачем перетирать одно и то же 10 тысяч раз разными словами, теряя по дороге частицы смысла?
RUP для веба - это мощно. Издержки на его ведения покрываются только если проект огромен, как уже говорилось выше - надо что-то более agile ;)
12 ...
34

Information

Rating
Does not participate
Location
Зеленоград, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Scrum Master
Lead
From 5,000 €
PHP
OOP
Git
Agile
Business process management
Project management
JavaScript
MySQL
Web development