- Home
- Sobre
- Arquivo
- Fórum
- Games
- Mobile
- Fotografia
- Games DB
- Colabore
- Anuncie
- Radar
- Minha conta
- Contato
- Feed completo
- Feed dos comentários
- Feed do Fórum
- Feed Canal Games
- Feed Canal Fotografia
- Feed Canal Mobile
- Receba o Meio Bit via e-mail
Fórum
Criar novo tópico no fórum Últimos tópicos no fórumÚltimas respostas no fórum
- Aniversáriante do Dia...
- Empreendedorismo na escola com Amazon Kindle
- Como fazer o GCC (MinGW) se dar com GLib?
- Samsung Galaxy - vários problemas
- Vendo L4D2 PC
- Onde Importar um PS3
- Canon SX1 iS-dúvidas
- Baixaki
- Conexão wireless lenta com senha
- Problema com MP4
- Warner.Jp libera poster do filme de Tekken
- Net, note ou desktop?
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
Categorias
- Acessórios | Acessórios | Acessórios | Análise | Análises | Anúncios | Anúncios | Apple e Mac | Artigo | Artigo | Áudio Vídeo Fotografia | Blog | Celular | Celulares | Ciência | Computação móvel | Computadores | Comunicação Digital | Cultura Gamer | Destaque | Destaque | Dicas | Download | Ensaio | Entrevista | Entrevista | Equipamentos | Especial | Fotografia | Galeria | Games | Games | Google | Hardware | Indústria | Indústria | Internet | Jogos | Lentes | Linux | Linux | Manipulação digital | Meio Bit | Mercado | Microsoft | Miscelâneas | Miscelâneas | MMO | Mobile | Mundo Estranho | Museu | Nintendo | Notícias | Open-Source | Opinião | Periféricos | Planeta Sem Fio | Podcast | Portáteis | Preview | Produtividade | Propaganda & Marketing | Publicidade | Resenha | Rumores | Seguranca | Software | Software | Sony | Tutoriais | Tutorial | Tutorial | Unboxing | Vídeos | VoIP | Web 2.0 | Web Games | Wireless e Redes |
Escolheu?
O que você diria, então, quando um diretor de uma empresa diz que não vai dar treinamento algum para uma equipe porque é caro. Não vai contratar profissionais experientes nas tecnologias porque é caro. Tem um projeto difícil pela frente e demanda performance superior ao concorrente e com qualidade absoluta, ou seja, totalmente livre de bugs.
Loucura? Certamente, mas nunca uma área atraiu tantos loucos e idiotas como tecnologia.
Bom = Qualidade
Em primeiro lugar, a maioria dos gerentes não faz idéia do que é qualidade. É o pior termo possível para projetos tecnológicos porque pode significar objetivos e percepções diferentes de quem está analisando. Uma analogia com carros (adoramos carros, oras) para ilustrar o conceito de qualidade: uma Ferrari é um excelente automóvel, ninguém duvida. O cliente precisa de um automóvel e você entrega a Ferrari dos softwares e o cliente diz: não queria a pintura excelente, não queria a velocidade, nem mesmo o acabamento… tudo o que eu queria era cortar grama mais rápido.
Quando um cliente diz que a qualidade deve ser total, tenha certeza e escreva, grave, registre de alguma forma, o que é a qualidade para essa pessoa. Muitos projetos fracassam porque na percepção dos programadores, os algoritmos, as fórmulas devem funcionar corretamente, com precisão e a interface fica em segundo plano. E o projeto é sistematicamente recusado porque as tonalidades de azul escolhidas não combinam. (sério, eu já ouvi isso)
Barato = Custo
O custo para produzir software está principalmente no profissional. O empresário ruim é aquele que enxerga uma pessoa bem remunerada como um gasto para a empresa sem considerar o valor agregado do mesmo: capacidade de inovação, conhecimento, experiência, abstração, raciocínio e resolução de problemas. Repare que não estamos falando em linhas de código por dia ou pontos de função por semana.
Custo baixo é algo muito relativo, mas normalmente resume-se a vender o projeto por um preço abaixo do que ele realmente vale e depois cobrar dos funcionários horas extras não remuneradas para acobertar a cagada da equipe de vendas. Você sabe, aqueles zumbis que vendem software como se vende aspirador de pó.
Se o custo precisa ser baixo, escolha dois itens para sofrer consequências. Custo baixo com qualidade (interface linda e perfeita, por exemplo), você deve equilibrar em performance e prazo.
Rápido = Performance
O software performático é aquele que executa suas tarefas consumindo o mínimo de recursos do equipamento ou plataforma para o qual foi dimensionado. Programar e projetar software pensando em performance normalmente é necessário cortar alguma coisa dos outros dois. É um jogo difícil, eu sei, já que todos queremos criar o melhor produto possível. E a palavra-chave aqui é “possível”.
Logo = Prazo
Todo projeto precisa de um prazo. Se o prazo encurta, é preciso cortar o escopo, ou seja, a quantidade de trabalho a ser feita para que os outros itens não sejam afetados. Se você precisa modelar um sistema de vendas online, programar, documentar e implantar tudo no menor prazo possível ou imposto (o que normalmente acontece), seja o primeiro a informar qual das outras coisas devem ser cortadas.
Por exemplo, se formos cortar Qualidade, que para esse cliente é interface, ela terá que ser simplificada e todas aqueles badulaques e penduricalhos gráficos devem ser removidos. Se ele precisa também ser muito rápido, então obviamente não será possível reduzir assim tanto o custo.
Conclusão
O que realmente acontece é que as empresas decidem pelo menor prazo e menor custo e prometem menor prazo, altíssima qualidade e performance inigualável, mesmo que seja a primeira versão do software. Ou seja, mentem descaradamente e fazem isso principalmente porque o pessoal técnico não é envolvido.
O profissional precisa alertar, sempre, o quanto antes e se defender de todas as formas possíveis da crise que será gerada tempos depois. Queria saber de vocês o que mais fazer além disso? Negociar, procurar outro emprego, bater de frente, não dar garantia alguma?
E lembre-se sempre que “O ótimo é inimigo do bom” (Voltaire).
Fonte: Bicalho’s Memory About Fraked Up Projects
- Feed comentarios deste post
- Ricardo Bicalho's blog
- entre com seu usuário e senha ou registre-se no site para enviar comentários
Tentar argumentar, se não funcionar o jeito é bater de frente.
Se for demitido por falar a verdade (Sem justa causa) ganho meu direitos e procuro outro emprego, pra desenvolvedor emprego não falta.
______________________________________________________________
C2D E8400, GA-G31M-S2L, 2X 1 Giga Kingston DDR2 800 CL6, 9600GT XXX Edition, HD`s Hitachi 160Gb e Maxtor 250Gb, DVD-RW Samsung, Fonte 500W Reais Akasa. Microsoft Sidewinder Mouse, Xb
Cara, acredite, 90% dos empregos que você arrumar será assim. Este é o perfil do mercado, então procurar ser demitido para arrumar outro não é uma solução, apenas um refúgio. Digo isto por experiência própria.
O profissional de DEV hoje que é valorizado no mercado tem que ter além de habilidades técnicas, jogo de cintura. O que eu acho uma infelicidade danada
http://wallck.spaces.live.com/
wallace.go@gmail.com
Principalmente esse tal "jogo de cintura", pois muitas vezes os contratantes querem tudo pra ontem com e algo impressionante e do jeito que eles tem em mente, e não do jeito que ele te passou como ele queria que fosse. Aí entra muito jogo de cintura, pois a maioria dos usuários não sabem o que querem e acaba sobrando para o desenvolvedor.
Isso de ter que ter jogo de cintura é realmente uma merda.
Jogo de cintura = Capacidade aturar/enrolar pessoas estúpidas que acham que o mundo gira ao redor delas.
Eu não entendo como diabos um cliente ou chefe acha melhor entregar logo um sistema feito todo nas coxas que vai tarzer muito stress para ambas as partes e acaba que, se finaizado, vai levar mais tempo e sair mais caro do que se fosse feito tudo direito.
Seria mil vezes melhor ouvissem quem realmente entende do assunto em vez desses espertalhões do marketing. Polparia muitas dores de cabeça.
______________________________________________________________
C2D E8400, GA-G31M-S2L, 2X 1 Giga Kingston DDR2 800 CL6, 9600GT XXX Edition, HD`s Hitachi 160Gb e Maxtor 250Gb, DVD-RW Samsung, Fonte 500W Reais Akasa. Microsoft Sidewinder Mouse, Xb
Bicalho,
Com certeza você já deve ter lido por aí ou ouvido falar que mais da metade dos projetos de tecnologia fracassam, exatamente pelos motivos citados no post.
O cliente sempre quer seu projeto feito para ontem, e o que mais vemos por aí é os caras vendendo mundos em recursos, tecnologia, escopo bem abrangente, por um prazo bem curto (bem subdimensionado) e sem pessoal com capacidade técnica para executar tal tarefa.
Se fomos fazer tudo certinho, levantando bem os requisitos, fazendo as análises de viabilidade, essas coisas, a verdade é que o cliente acaba recusando o projeto pelos fatores tempo e preço (quanto maior o tempo, o preço tende a ser maior também, proporcionalmente).
Acho então que a culpa dos projetos fracassarem não está só na mão das empresas de tecnologia, em nós que desenvolvemos sistemas, mas boa parte disso ocorre justamente do lado do cliente também, que sempre quer mais coisas além do contratado, que deixa-se levar pela proposta "BBB - Bom, Bonito e Barato" dos vendedores e que NUNCA é verdade, etc.
Dicas de Programação, utilitários, análises, opiniões sobre tecnologia e afins?
http://neomatrixtech.leonelfraga.com
Ler um texto destes depois do Programa do Alborghetti que o site virou esta semana é um alento...
Eu ainda gostaria de ver você escrever algo sobre as experiências sobre equipes de desenvolvimento. Acho que o trabalho em equipe e as regras deste (no âmbito da informática) praticamente a força motriz de um ótimo trabalho.
Sabe tipo uma guilda de um jogo online? Não sei se vou conseguir ser claro em meu raciocínio:
Seja qual for as "opções" que a empresa escolha (exceto o preço), eu creio que o tempo de desenvolvimento, a qualidade final nos diversos aspectos de um software e o consumo de recursos são, além de frutos de um bom trabalho, um resultado do equilíbrio de uma equipe escolhida por um bom gerente de TI.
Como ter um healer, um que ataca, um bom de magias e um personagem rápido, funcionando juntos.
Porque digo isso? Porque já ví projetos que a equipe era um paraíso de "monocultura": Todo mundo era essencialmente bom em programar, mas não tinha um cidadão que soubesse criar alguma interface no mínimo decente. Ou um monte de caras bem atualizados e ótimos programadores, só que lesmas.
Se você monta sua equipe de TI com cinco lesmas competentes, não adianta alguém vender prazo, porque não irá sair. Se na equipe tem um monte de encaixador de módulos, não adianta vender rapidez.
Acho que uma equipe mal formada é o pior empecilho para um projeto bem realizado. E afirmo categóricamente que são pouquíssmos os gerentes que procuram montar uma equipe heterogênea.
Sei que não tem muito a ver com o post em específico, mas achei legal dizer isso, antes que eu me esquecesse.
Concordo.
Eu por exemplo, me acho (ainda bem q meu chefe também acha
) bom para programar, em ter idéias, analisar processos, porém sou tosco em design de interfaces.
Até que estou me virando bem com isso, mas nada que se compare com um trabalho feito por um designer mesmo.
Uma equipe para um projeto, tem que ter gente especializada em cada parte: analistas, programadores, designers, helpdesk, etc.
Sendo cada um especializado em sua função, até dá para vender qualidade e prazo, sendo que para isso, os caras tem que ser bons no que fazem para não ficar um dependendo do outro, e ter um bom cuidado para o projeto não entrar em um "deadlock" por causa de uma das etapas.
Em empresas pequenas, é muito difícil acontecer isso, de ter uma equipe dedicada a um projeto, sendo mais comum 1 programador assumir o mesmo.
Por exemplo, programador fazer as vezes de helpdesk, prestar suporte ao usuário.
Na minha opinião isso derruba a produtividade e a paciência, principalmente se você está resolvendo um p* bug em um projeto de um cliente X e de repente o telefone toca e você precisa atender um cliente Y.
Mas, dependendo dos clientes, não vejo muitas trevas nisso, pois se acaba tornando um aprendizado, e como eu digo, nessa área de análise de sistemas (nem tanto a programação), você acaba conhecendo (mesmo que superficialmente) várias áreas de negócio.
Dicas de Programação, utilitários, análises, opiniões sobre tecnologia e afins?
http://neomatrixtech.leonelfraga.com
Tem um post engavetado sobre isso. Vou caçar ele.
Assino embaixo, Fabião!
Uma equipe bem formada já é meio caminho andado.
Estou esperando o post sobre este assunto Bicalho!
Esse post demorou pra sair heim!
Como comentei em outro post, só o Cardoso estava levando o MB nas costas.
Os posts eram todos sem graca e de certa forma irrelevantes.
Não entenda mal o meu comentário, mas eu gostaria de ver mais posts como esse.
Sem problemas!
Mais posts com esse estilo, então.
Concordo contigo, apesar de ter ficado off umas semanas, percebi que não perdi muita coisa importante, somente "noticias" e não "debates".
Deveriam haver mais posts tecnicos, onde a troca de experiência é mais intensa.
COncordo, não sei o que ta acontecendo mas até o Cardoso perdeu a capacidade de sarcasmo.
Oh, god.
2 coisas acontecem:
- Muita gente que compra programa acha absurdo, pois acha que o programa que o vizinho tem no CD pirata é melhor e faz tudo o que ele precisa. Se não, o filho pega um e passa crack.
- Quem vende acha que deve fazer o suficiente para entregar o programa, e esse suficiente implica em fazer a interface e a arquitetura de informação do jeito que ele acha que vai ficar bom.
Resultado: quem paga quer pagar pouco e quem faz acaba fazendo algo bem diferente do que quem paga queria.
Deus Ex Machina
Se não, o filho pega um e passa crack.
É mas isso que você tá falando são programas de prateleira.
Estamos falando de sistemas específicos como sites, ou aplicações que resolvam um problema específico do cliente.
Pra se ter idéia recentemente terminamos um sistema, e para customizar 1 procedure de 200 linhas mais umas 3 modificações de tela, saiu por quase 1 milhão de reais para a Brasil Telecom.
Esse não é o tipo de software que se acha no Pirate Bay e que se aplica um crack.
E esse é o sistema que se participa de 3 meses de reuniões/ planejamento, viagens, e produz toneladas de documentos, etc
Já escutei uma vez (não sei de quem ou onde) que todo cliente deve escolher 2 B's entre os 3 existentes... (BOM / BONITO / BARATO).
Os 3 juntos NUNCA vai acontecer...
Se for bom e bonito, não vai ser barato.
Se for barato e bom, dificilmente vai ser bonito.
Já se for bonito e barato, é bem possível q não seja bom.
E é mais ou menos por aí q as coisas acontecem...
[ ]´s
Marcelo Sales
Deve ter sido o Edward Yourdon.
Não duvido... já que é quase certeza que eu tenha escutado isso na época da facul...
...nunca mais esqueci...
[ ]´s
Marcelo Sales
Gostei dessa maneira de pensar
É praticamente um mantra!
[ ]´s
Marcelo Sales
Frase de um administrador de redes filósofo: "O pessoal do comercial vende a mãe deles e entrega a dos técnicos."
Infelizmente essa é a realidade em que vivemos, o cliente não quer pagar muito e concorda que a equipe de 3 pessoas é o suficiente, só que no meio do caminho ele muda os rumos e pede pra esses 3 fazerem coisas completamente diferentes da proposta original (que continua viva e precisando de alguém para executa-la) ai o que acontece? Aha! 1 Tib pra quem respondeu "ATRASA!"
É isso ai pessoal, o lance é evoluir na área administrativa, quando mais você administra mais informações técnica se perdem na sua cabeça e você "emburrece" em alguns dias
Outra filosofia? "Pra mim virar gerente, basta esquecer tudo o que já estudei"
_____
"Um gênio é 1% de inspiração e 99% de transpiração." - Thomas Edison
Ótimo post!
É isso que eu falei, quando comentei sobre ter também posts trabalhados e bem elaborados e não o padrão "olha isso aqui legal que eu li no site X".
Sobre o assunto, é realmente difícil argumentar com os gerentes sobre prazos e falhas no projeto. A parte mais prejudicada normalmente é a fase de testes. Já vi muito projeto ser entregue com falhas para "arrumar depois".
Mas quando saímos de uma empresa e nos tornamos chefe, a coisa não melhora muito. É a mesma discussão de valor e prazo com os clientes.
C'est La Vie.
Bicalho, você poderia pegar quatro palavras do japonês que comecem pela mesma letra contendo o significado dos quatro adjetivos (bem, nem todos são, mas é adaptável). Feito isso, cria-se um novo método como os 5 esses. Crie uma regra e está criado um novo programa de qualidade. Dê preferência às letras "R" e "B" (Ricardo ou Bicalho): os 4-R (quatro erres) ou os 4-B (quatro bes).
PS: 4 erres já existe: Repensar, Reduzir, Reutilizar e Reciclar (uma boa técnica para criar posts).
Ótimo post!
É isso que eu falei, quando comentei sobre ter também posts trabalhados e bem elaborados e não o padrão "olha isso aqui legal que eu li no site X".
Até você salsinha trocou avatar, o Lester se foi...
é a nova tendência?
__________________________________________________________
"Somente a Beira do Abismo que nos vemos Obrigados a Evoluir"
Luto pela briga do Bigode com o Fabião (e a expulsão do primeiro).
É a nova tendência
Um ótimo post sem dúvidas...
Pra um bom profissional, não dar garantias do serviço seria uma opção pouco viável.Porque já se sabe, qualidade acima de tudo.
Então chega a opção Negociar,tentar chegar a um meio termo com o chefe.
Quanto ao prazo, sabe-se que a rapidez muitas vezes é inimiga da qualidade, fazer algo bonito e pouco eficiente? é melhor bater de frente.
_______________________________
Novos Horizontes
Como eu disse anteriormente, um profissional de DEV (de TI en geral) hoje é valorizado no mercado por suas habilidades técnicas (pré-requisito) e pelo seu "jogo de cintura", ou seja, habilidades de negociação e trabalhar sobre pressão, sem impactar negativamente nos resultados, muito pelo contrário inclusive
.
Se repararem bem nos processos de qualquer empresa, todas as áreas são assim:
Setor de Compras fazendo pressão no Setor de Engenharia para minimizar o custo de produção, então a Engenharia tem algumas opções: trocar componentes, trocar de fornecedor, passar a pressão para o fornecedor criar equipamentos mais baratos, etc.
Todo este processo, no final, é para tentar fazer as modificações que cumpram o objetivo e não gerem um grande impacto na qualidade, e por aí vai. Fora o escopo do tempo, que com certeza o Setor de Compras passa para a Engenharia que passa para o Fornecedor.
Esse é o mundo do mercado, diferente do mundo da pesquisa, onde a qualidade alienada com o resultado possui maior ênfase.
http://wallck.spaces.live.com/
wallace.go@gmail.com
Muito clichê isso!
O mais comum é a triade Tempo, Qualidade e Custo. Escolhe duas e a não escolhida será a caracteristica que não pode ser cobrada no projeto.
Em geral, a teoria é linda, é uma literatura romantica para gerênciamento de projetos.
Ná prática seu chefe que que se @#$%. Ele vai querer CHEIO DE ÓTIMOS RECURSOS, PARA AMANHÃ e SEM TIRAR UM CENTAVO A MAIS DO BOLSO.
[]´s
Juliano Oliveira ->
http://programandoem.net
Exato. Haha, lembro como se fosse ontem as aulas de Gerencia de Projeto de Software, o professor falava exatamente a mesma coisa
Empresas estão tendo sucesso fazendo o uso de Metodologias Ágeis para o desenvolvimento de software. Quando digo sucesso, digo Qualidade, no Tempo certo, com os Recursos disponíveis. (existe bom senso aqui, ehehe).
http://wallck.spaces.live.com/
wallace.go@gmail.com
Pra se ter uma ideia de como isso é real, basta ver os anuncios de vagas de emprego, ex:
-Exige experiencia em windows 2003, ad, exchage, linux, samba, postfix, qmail, banco de dados oracle, sql server, mysql, apache, tomcat, c++, c#, asp, php, hardware, fazer cafezinho, atender o telefone, etc
Desejavel certificação Microsoft e Linux.
Salario 1000,00 mais beneficios...
É assim, e depois dizem que é dificil achar profissional, ou seja, mal de obra escrava é isso que o Mercado quer.
As vezes quando tem vaga de emprego no br-linux, só pra satirizar o Augusto coloca o "S" de superman na noticia.
O pior é que tem uns imbecis que aceitam vagas nesse estilo, subestimando o valor de mercado, fazendo com que o valor-médio do profissional diminua.
Para esse tipo de proposta, eu procuro responder assim: "1000,00 por dia, né?"
"O único lugar onde 'sucesso' vem antes de 'trabalho' é no dicionário."
Albert Einstein
Apresentar as qualidades do software que o cliente deseja da seguinte maneira: Vocês desejam um software como? Escolham duas das três características abaixo
a) Bom (Qualidade)
b) Rápido (Tempo de entrega do produto final)
c) Barato (Custo do serviço)
Huahauhauahauahuahauh... é até engraçado se não fosse trágico, mas acho que esse é um problema "sem solução", a menos que o pessoal técnico esteja diretamente envolvido na negociação de valores e prazos com o cliente.
-------------------------
Tenho um Macleod dos consoles em casa. O último membro do clã dos Macleods.
Eu trabalho a 23 anos na área de TI e posso garantir que essa discussão já era antiga muito tempo antes. Como o MSales citou acima, dos 3 B's, somente é possível ter 2 em um projeto.
Pessoalmente, tenho procurado trabalhar com empresas que não se importam com o "Barato", como as da área financeira. Devido à criticidade dos seus sistemas, performance e ausência de erros são condições essenciais. E eles sabem que esses resultados não se conseguem com profissionais "baratos" (apesar de ocasionalmente prazos inviáveis serem propostos para as equipes) e com baixos investimentos.
Na época que eu trabalhava com empresas menores eu conseguia reduzir prazos (e conseqüentemente os custos - o "B" do Barato) utilizando uma biblioteca completa de funções, templates e ferramentas para desenvolvimento. Dessa forma, podia me concentrar nas regras de negócios.
Além disso, não entregava todos aqueles artefatos de UML que hoje se exigem (a documentação ficava sempre dento do código-fonte, que era fornecido para o cliente conforme o contrato). Com isso, dava ao cliente uma sensação de que ele estava conseguindo receber os 3 B's.
O que eu nunca abria mão era do "B" de Bonito (telas com apresentação impecável e diagramação consistente são fundamentais e são o que realmente importa para os "chefes") e do "B" de Bom (sempre me orgulhei de produzir um código-fonte otimizado, documentado e com bom performance).
Apesar de ter levado alguns prejuízos por não abrir mão da qualidade (levava mais tempo do que os esperado em alguns casos), acabei ficando conhecido por produzir bons sistemas, o que acabou resultando em indicações para empresas maiores, onde a qualidade era valorizada e bem paga.
Olhando para trás, continuo acreditando que fiz a aposta correta...
Salada de Bits
Por isso que as metodologias ágeis funcionam tão bem, pois ao adotá-la o cliente necessáriamente tem que estar envolvido e ele decidirá o rumo do projeto. Cada fase (marco) é o cliente que decide que características serão implementadas e ele saberá na hora o custo disso, ja que nas reuniões semanais sempre devem estar presente uma pessoa tecnica (analista, programador), cliente e gerente de projeto. E como as revisões são em curto prazo (normalmente uma semana) sempre há tempo de corrigir a rota a tempo e sempre o cliente saberá o que está acontecendo e o que sairá no final.
Muito bom o post!
Acho que para não haver muitas dores de cabeça, a comunicação aberta é essencial, sem ficar com medo de discutir a realidade do projeto. Pois a maioria dos problemas ocorridos é devido a falta de comunicação entre os envolvidos.
Quando leio esses "Bicalho’s Memory About Fraked Up Projects" imagino que no final ele vá dizer: "pois é, estou falando da vida do Denis" akakakaka...
Acho que é assim em todo lugar. O negócio é deixar claro e mentir, como eles fazem.
"É pouco tempo. Vou fazer o possível. Acho que conseguiremos."
Primeira frase: ser claro.
Segunda frase: garantir o emprego.
Terceira frase: mentir.
Isso garante um...
"Eu avisei que não ía dar tempo."
... e se garantir, entregando algo bem feito.
Pelo menos eu faço assim. Se é pra ser mal feito, não faço. Se entregar no prazo e ficar uma m*, você vai ser tachado de incompetente. Já vi muita cara feia por causa da demora, mas também já recebi muitos elogios e isso é o que conta, pra mim.
Na minha área de trabalho, há muita pressão com relação as datas de entrega de projetos. Muito trabalho e pouco tempo hábil para entrega.
Por experiência, sei que correr demais para entregar grandes projetos para satisfazer a sede de seus gerentes, pode resultar em erros no produto final. Eu, particularmente, primo pela qualidade do meu trabalho em primeiro lugar. Mesmo sendo precionado com relação a prazos de entrega, bato de frente e digo não aos prazos que considero absurdos.
Na maioria da empresas, ainda mais com a crise e muitas demissões rondando o povo, muitos se sujeitam a aceitar o que seus superiores mandam, sem questionar, com isso, quem vai se prejudicar é ele próprio.
Tenho contatos em uma multinacional próxima aonde moro, que liberou em off, que, aproveitando o "gancho" da crise para evitar reclamações, vai demitir funcionários, e os que estão mais próximos da mira, serão aqueles que a empresa considera como não produtivos. Em outras palavras, funcionário "problema", os que não correspondem a seus cargos, desafetos,etc., Com isso, a empresa vai contratar novos funcionários com menor salário.
Não li todos os comentários.
Mas um dos problemas que vejo é que muitas vezes a empresa negocia "demais" um projeto.
Acredito que se ela assumisse a posição, um exemplo, só vendemos bom e bonito, os projetos dessa empresa teriam mais chances de sucesso.
Eu ja vi uma empresa usar a estratégia de pegar um projeto e dividir em vários e ir vendendo aos poucos ao cliente.
-------------
Me abstenho...
só vendemos bom e bonito
Apple + S. Jobs
http://wallck.spaces.live.com/
wallace.go@gmail.com
Boas,
Sobre prazos impossiveis, costumo dizer o seguinte:
Eu tenho um acordo com Deus. Ele não programa e eu não faço milagres.
E não arredo pé quando querem que eu dê uma estimativa de 3 semanas, quando na realidade são três meses, ou então, nem sabem bem o que é para fazer.....
Abs
XiriX
Essa "pressa" ocorre nos serviços de infra também, espera-se sempre redução de prazo, com o menor preço possivel, e ainda querendo que tudo funcione que nem um relógio sem erro nenhum. Complicadíssimo!
--
Atenciosamente;
Diego M. Proença
MCSE-MCSA-MCTIP-MCTS-MCDST-MCP