Хроники пикирующего, кабрирующего, горкирующего програмера.

SmartDesign, тю, господи, неужели в этом рассказе есть нечто оригинальное?
Впрочем, я тоже жду продолжения.

Цитата ("Novick"):

Цитата ("FlaPS_Team"):

Цитата ("tvv"):

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

tvv, Аплодирую стоя, никогда так не сравнивал, но ведь насколько верно.

Не знаю, не знаю. Я, лично, больше раза с девушками не общаюсь. Так что рекомендую "девушкам" использовать момент по максимуму.

Может поэтому вам с "девушками" (имеются ввиду конечно заказчики) и не очень везёт :P ,

FlaPS_Team, Вы меня поражаете своей прямотой. С чего Вы вздумали, что я сижу на сервисе, и жду не дождусь, когда мне ярмо на шею накинут? Я уже говорил, и не раз: моя цель - деньги. А когда мне просто хочется поработать (очень редкий, маловероятный случай), я занимаюсь уборкой в квартире.
В этой теме мы столкнулись с типом исполнителя, который, в отличие от меня, любит работу. Вот давайте смотреть, к каким последствиям это ведёт...

Чет не разделил всеобщей радости по поводу вышенаписанного... наверное слишком гламурно:unsure:

Так причем тут радость, познавательно ООООчень, Автор, ждем продолжения

Часть. 3. Трехголовый змей ищет друзей.

Вернусь к самому началу нашей работы. В команду объеденились 3 человека, на условиях равноправия. Т.е. решения принимаются согласованно со всеми. Речь идет о политических решениях, а не о программерских. Т.е. направление нашего развития, какие-то концептуальные вопросы. С одной стороны хорошо - демократия, никто не обижен. Но с другой стороны всё далеко не так хорошо и рано или поздно один будет за, другой против, а третий воздержится. В общем схема в которой нет высшей инстанции должна была привести в какой-то момент к конфликту, причем понимал я это с самого начала, но выбора у меня не было.
Думаю каждый из нас троих считал (и считает) себя равным, но немного равнее, чем другие. В общем конфликт случился, было принято какое-то важное решение без согласования со мной. Что именно за решение я уже не помню, наверное, на самом деле, оно было не столь важным Ну в общем я устроил сцену ревности с разбрами полетов и т.д. В конце концов меня попустило конфликт был улажен и всё вернулось в свое русло. Схема нашей работы не изменилась, команда не распалась, однако я до сих пор убежден в порочности такой схемы.

Примерно в то же время, когда произошел конфликт, я понимаю что есть новая проблема. Я иногда не знаю, кто сейчас трудится, а кто нет, и вообще чем заняты бойцы. Также у нас расширяется кол-во заказов и приходится приглашать на помощь товарищей. Эти два события заставляют задуматься над учетом рабочего времени. Кто сколько трудится и трудится ли вообще. Начинаются поиски софтины позволяющей учитывать рабочее время, стоимость времени для сотрудников и стоимость этого же времени для заказчика. После перебора кучи вариантов я останавливаюсь на этом ссылка После доработки напильником программа может хорошо выполнять все необходимые функции.

Теперь немного про то, как мы приглашали к работе новых програмистов. Ситуация примернр следующая: иногда у нас начинают появлятся заказы с которыми мы не успеваем справлятся, однако еще нет базы, которая позволила бы нанять полноценно программиста на ежемесячную оплату. Что делать? Начинаем спрашивать толковых студентов на последних курсах, друзей, знакомых и т.д. на предмет сделать шабашку. Народ понемногу откликался. мы давали небольшие работы и смотрели, кто что делает. В общем так через нас прошла кучка народу, большая часть которых отсеялась, но осталась пара человек с которыми начали постоянно работать.
Кстати о студентах. Есть потенциально очень толковые студенты, у них дофига энтузиазма, быстрые мозги и хорошая память, но нет опыта. Работа с ними без пристального присмотра приводит к очень забавным результатам в написании кода. Ну например засунуть блок оптимизации (по логике отдельная большая сущность) в класс базы данных. И получается как в том рассказе про рассеянного с улицы Бассеянной: "Побежал он в кассу покупать бутылку квасу". В общем пришлось долго доказывать что не надо смешивать принципиально разные вещи в одном классе.
Тут я вынес еще один урок: по началу молодых бойцов надо очень внимательно контролировать, и доверять самостоятельную работу только когда удостоверишся, что нет откровенных ляпов. Наиболее правилно самому выполнять проектирование, делать заглушки и просить эти згалушки наполнить кодом.

С появление у нас новых бойцов приходит конец разгильдяйству с деньгами. Нужен, как минимум, нормальный учет. (До планирования еще далеко. Слишком мы зависим от Фортуны ) Благо рядом были нормальный бухгалтер и заходя раз в неделю-две делал все проводки. Т.е. я в течении недели накапливал чеки, листочки (мне друг подогнал 2 ящика перфокарт. удобные листики ) с записями о приходах, тратах и т.д., а бухгалтер нормально это оформлял.
В команде особой популярностью пользовались месячные отчеты о деятельности команды. Положительные отчеты. Отрицательные отчеты успехом не пользовались.

В это же время я рисую большую таблицу в экселе которая позволила бы понять сколько я должен брать с заказчика если у меня N отцов-основателей, M - наемных работников, P% простоев, S% налогов, всякая аммортизация компов, стоимость офиса, и т.д. Грубо говоря получается, что если нас трое отцов, и у нас трое наемных рабочих, простой 30% времени, час стоит 7 уе, ЗП рабочих 600 уе отцы имеют ~980 уе... Но не всё так просто... Иногда простои бывали покруче чем 30%

nobunaga, хорошо и интересно написано.
Может оформить и выложить как статью?

Цитата ("alibek"):

nobunaga, хорошо и интересно написано.
Может оформить и выложить как статью?

Главное дописать. Я может потом и книгу издам.

Книгу?
Ну если она будет на уровне "Как пасти котов", то почему бы и нет

Та, я стебусь на счет книги.
В принципе если то, что я пишу интересно, то я могу в конце оформить как одну статью. Я не вижу в этом проблем.

Маленькая часть между 3 и 4. Рассуждения в летнюю жару про поекты с нуля и про багофиксные проекты

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

Если у тебя есть проект который ты делаешь с нуля, то как правило ты договариваешься на какие-то варианты типа фиксированной суммы или поэтапного формировния суммы работы, типа как рекомендуют XP-шники. Работа делится на куски (итерации), оценка первой итерации, выполнение её, оценка второй итерации на основании опыта полученного от первой и т.д. В любом случае делается оценка проекта с определенной долей неточности и риска.

Так вот. С проектами в которых надо выполнять багфиксинг, имхо, это не работает. Неточности и риски на проядок больше чем в проектах с нуля. Мне кажется нельзя сделать оценку сколько займет фикс какой-то баги. Фикс может быть как очень простым в одну строчку, так и концептуальным (например переделать структуру БД, с сохраением данных, а данных 5 миллионов записей (как можно столько записей получить на глючной проге?) ). Может есть люди которые в состоянии с первого взгляда оценить что есть багофикс и как трудно его делать, но я прихожу к мнению, что сделать корректную оценку невозможно. Поэтому проекты про багофиксы надо старатся выторговывать почасово или же договариватся о каких-то переоценочных этапах.

Это я о наболевшем. Взялись мы как-то за 200 уе пофиксить баги. Сказали 2 дня работы...

Цитата ("alibek"):

Может оформить и выложить как статью?

Пусть издатели беспокоятся. Я и так с удовольствием почитаю.

История очень похожа на то, как мы начинали. Но без таких "попаданий" - по крайней мере на деньги не попадали и настолько со сроками не ошибались - наверное мы просто более далекоглядными были, тьфу-тьфу-тьфу. Но в тексте узнаю нашу историю почти двухгодичную.

Цитата ("tvv"):

Продолжение будет в стиле: "....А потом я поставил себе Rational Rose, Requisite Pro и Clear Case, и стал работать по RUP-у. Убедился, что это имеет смысл только для проектов с бюджетом от 1.000.000 (а может и более, но я пока об этом не знаю), но слово модное..." ?

А на проектах от 100.000$ что хорошо?
ИМХО, RUP окупится далее при сопровождении и апгрейдах. Ибо без него всё сводится к отдельным личностям, которые "что-то помнят", зачем делались те или иные изменения в программе, зачем добавлялись поля в таблицы.
Да и как тестер скажу: тестировать подобные системы ручными метода плохо и геморно, а писать тесты к этому - ещё более геморное занятие

Цитата ("nobunaga"):

Так вот. С проектами в которых надо выполнять багфиксинг, имхо, это не работает. Неточности и риски на проядок больше чем в проектах с нуля. Мне кажется нельзя сделать оценку сколько займет фикс какой-то баги. Фикс может быть как очень простым в одну строчку, так и концептуальным (например переделать структуру БД, с сохраением данных, а данных 5 миллионов записей (как можно столько записей получить на глючной проге?) ). Может есть люди которые в состоянии с первого взгляда оценить что есть багофикс и как трудно его делать, но я прихожу к мнению, что сделать корректную оценку невозможно. Поэтому проекты про багофиксы надо старатся выторговывать почасово или же договариватся о каких-то переоценочных этапах.

В не своей проге, не зная досконально её внутренней структуры правильно оценить необходимы трудозатраты нереально! Это гадание на кофейной гуще. И ещё надо иметь представление о том, в каком виде к вам придёт баг: ввиде минимизированного бага (область появления бага сужена до минимума) или же "письма на саппорт" (у нас не работает отчёт).
Вы же сами написали, что оценка итераций проводится с учётом предыдущего опыта.

Цитата ("nobunaga"):

Неточности и риски на проядок больше чем в проектах с нуля. Мне кажется нельзя сделать оценку сколько займет фикс какой-то баги...

Почему? Вопрос удачи! Вы на удачу не рассчитываете?

Цитата ("SolNikolay"):

А на проектах от 100.000$ что хорошо?
ИМХО, RUP окупится далее при сопровождении и апгрейдах. Ибо без него всё сводится к отдельным личностям, которые "что-то помнят", зачем делались те или иные изменения в программе, зачем добавлялись поля в таблицы.
Да и как тестер скажу: тестировать подобные системы ручными метода плохо и геморно, а писать тесты к этому - ещё более геморное занятие

Ну, мне кажется, что код надо писать так, чтоб не зависить от личностей, и руп тут особо ни при чем. Во первых я придерживаюсь того, что в коде не должно быть "трюков". Чем проще код - тем лучше, моя задача не показать своим кодом какой я умный а решить задачу и чтоб программа была поддерживаемой другими програмерами. Во-вторых шаблоны проектирования, имхо, должны широко использоватся, причем основная причина их использования даже не, то что они описывают какие-то проектные решения, а то что они дают названия шаблонам и разработчики могут между собой оперировать "крупными" понятиями, что ускоряет взаимодействие. И третье. Тесты ускоряют разработку кода! По нескольким причинам. Если пиштся сначала тест, а потом код, то четче в голове структурируется само решение, и второе - экономия времени при внесении изменений и дебаге.

Цитата:

В не своей проге, не зная досконально её внутренней структуры правильно оценить необходимы трудозатраты нереально! Это гадание на кофейной гуще. И ещё надо иметь представление о том, в каком виде к вам придёт баг: ввиде минимизированного бага (область появления бага сужена до минимума) или же "письма на саппорт" (у нас не работает отчёт).
Вы же сами написали, что оценка итераций проводится с учётом предыдущего опыта.

Описания багов, как правило "письмо на сапорт" Про гадание на кофейной гуще согласен, но итерации тут не помагают. Допустим надо пофиксить 5 багов. И нифига же не понятно, во-первых как бить жалкие 5 багов на итерации Во вторых, ну, допустим баг - итерация. На первые 4 бага ушло 1 час на каждый, а на 5 уходит 3 дня. И как тут планировать?

Цитата ("Novick"):

Цитата ("nobunaga"):

Неточности и риски на проядок больше чем в проектах с нуля. Мне кажется нельзя сделать оценку сколько займет фикс какой-то баги...

Почему? Вопрос удачи! Вы на удачу не рассчитываете?

На удачу надо рассчитывать когда уверен на 90%

nobunaga, ну насколько я помню RUP - тесты и код пишутся параллельно. А не "сначала тест, а потом код"