Наткнулся тут на высказывание, которое показалось интересным
"Если не сожрали в момент выхода на рынок, почему должны сожрать потом? Как правило, дохнут шароварщики по другой причине - решают стать "как большой", нанимают кучу программеров и сейлов, десять программеров работают хуже одного отца-основателя, но ЗП жрут немерянно, сейлы какое-то время поддерживают рост путем все увеличивающихся расходов на маркетинг, потом контора начинает падать. При этом выясняется, что за несколько лет игр с наемными программерами продукт почти не развивался, а конкуренты худо-бедно продвинулись, первоначальный запал пропал и бежать вдогонку сил нет. Усе."
С одной стороны, все очень правильно (правда тут надо учесть, что 99 из 100 шаровар загнется еще до того момента, как появится возможность кого-то нанять).
Но есть и другой момент. Дохнут на мой взгляд, не от того, что "десять программеров работают хуже одного отца основателя", а от того, что работать все это продолжает в том же самом режиме, что и когда "отец основатель" хреначил в одно рыло. Т.е. в самом по себе расширении ничего дурного нет, дурное оно в расширении, без изменения процессов производства.
Т.е. здесь ты обходился без тех. задания и оценки времени разработки, потому что тех. задание было в голове (ну в крайнем случае в виде 10 пунктов в notepad), а время оценивать было не надо, фитчи которые не успевал сделать просто резались на ходу. Там комментарии в коде были не нужны, да и code style был один - тебя устраивающий. А когда программистов стало 10, пожелание, "сделайте вот это", вместо тех. задания, выливается в то, что делают в лучшем случае что-то похожее, в худшем вообще не пойми что. А отсутствие предварительной оценки времени разработки, приводит, к чтению форумов и повышению общего образовательного уровня программистов, а отнюдь не к быстро сделанному коду.
Комментариев нет:
Отправить комментарий